想问问各位大佬，平日开发异常是怎么处理的。

[Renco]

曾经写了一段代码，在最逻辑外层捕获了空指针，因为内部逻辑出现空指针一定是数据查不到导致的异常，所以方便处理，我统一在最外层捕获空指针打印 xxx 数据查不到的日志。结果被项目总监拿出来吐槽了。说空指针为什么要去捕获他。让我调整这段代码。然后我就得在内部逻辑判断多个 if 语句去 isEmpty 判断是否为空。。

就是想了解下，我原先这种处理方式是不合适还是异常本身就不应该去捕获再做逻辑判断。

[Renco]

有时候我会用，异常捕获来做一些逻辑操作，虽然比较少，这种处理模式是比较非主流的么

[abersheeran]

不建议最外层捕捉这种通用异常。因为你没办法保证这个异常会不会出现在其他你没想到的地方。

最外层捕捉异常的逻辑一般都是捕捉自己定义的异常，因为能清楚知道它会在什么时候出现、以及该如何处理。

[jjwjiang]

在可能为空的地方处理空值是一个码农的基本素养之一

[Renco]

@abersheeran 好吧 清楚了。

[Renco]

@jjwjiang 偷懒了，两年前写的代码被挖出来嘲讽一波 有点难受

[rekulas]

我也支持你总监的做法，你在外部捕获虽然表面方便但有这样的问题：
1 你可能很难确定空指针具体是哪个逻辑导致的
2 正常逻辑执行时如果不及时处理空指针有可能出现数据错误-一些本不应该执行到的逻辑被处理了，从而引起 bug
可能还有其他问题...

[Renco]

@abersheeran 那如果我能保证我捕获的这段逻辑出现的空指针是我能确定的，可以这样处理么。

[thinkershare]

主要要看你处于什么层次, 你做的这个层的消费者是谁, 如果你作为一个底层库, 要看错误是谁导致的, 如果是用户入参有问题, 我们就是抛出异常, 如果是内部的不受控的上下文依赖导致的问题, 也是直接抛给调用者, 如果是内部业务逻辑错误, 也直接抛给调用者. 如果是外部调用者(普通用户或第三方 API 调用者),那么就需要在外层统一处理一下. 主要是大部分错误就没法处理. 直接返回给调用者. 主要是看是逻辑错误还是其它. 说白了, 异常是一种偷懒的流程控制手段, 看你怎么用.

[Renco]

@rekulas 明白了，谢谢大佬

[hahaba]

做法不对，你既然捕获到日志中了，就应该再写个脚本定时删除异常日志，这样就不会发现错误了

[thinkershare]

另外, 对外在能考虑到的情况是不会抛出系统级别的异常的. 如果事前没有考虑到, 那么就让他直接奔溃. 由宿主层去考虑要怎么执行下一步操作.

[abersheeran]

@Renco 你没法保证空指针异常一定出自你的这个逻辑。你不是神，你怎么预测未来的代码不会抛出其他情况的空指针异常？

如果你坚持在外层捕捉你这段逻辑的异常，我的建议是你在你的代码逻辑那儿捕捉空指针，重新抛出一个你自定义的异常。

[Renco]

@abersheeran 可以，受教了

[chaoschick]

我也喜欢在 controller 层进行异常捕获，

[chendy]

空指针异常其实不方便统一处理，因为不知道什么东西是 null ，所以通常和其他异常一样，做为“系统异常”处理

一般做法是，业务逻辑里做 == null 判断然后抛自定义的异常 “未找到 xxx”，外加打日志 “id 是 xxx ，查询条件 xxx 的数据未找到”

[Saxton]

难怪你被吐槽。。 我最近接手到一个项目全部用 try catch 来判空和判非法值，有几个参数是直接 get 的，但并非必填的， 无语死，整个方法拿个 try 套起来，省了几个 if ，你这确实爽了啊，后期维护的人怎么办，吐血给你看吗

[Saxton]

越想越气，楼主你在哪

[AoEiuV020CN]

不做空判断的话 idea 会有黄色警告，哪怕只是为了消除警告都可以加个空判断，

[Saxton]

代码一大堆全部是拿 try 来充当 if ，哪里出问题我必须开调试，不然我根本不知道到底是哪一个方法抛的异常，关键还是捕获的 exception ，我该他的代码还得开个 debug 一步一步走看看到底哪里蹦了

[DonaldY]

平时代码多考虑会儿，该 throw 的 throw ，该 try 的 try ，有异常的地方打好堆栈。

蔸底拦截是应该有的，提示需要给用户友好，而不是把错误显示在页面上。