下面我们把镜头转向正在加班开发需求的几位选手, 看看他们是如何对待异常处理逻辑的;
----
round one
这是来自一个对try catch第一次使用的 #$%^选手
try {
.........此招式可使问题永远藏在 #$%^ 的代码中, 永远做一个"优秀的开发者", 相信他会在自己的梦想道路上渐行渐远
----
round two
这是来自一个对try catch第二次使用的 *&^% 选手...这种写法可以知道有问题, 但不知道哪有问题.
----
round three
这是来自一个对try catch第三次使用的 3号选手
try {
......
// 中间嵌套10个业务处理方法...// 写你自己的异常处理逻辑
}
我们看到, 这位选手使用了化骨绵掌伤害值 : 能够知道错误信息, 具体位置仍需分析;
伤害分析
这种操作对于我们自定义异常是有一定的帮助, 但单业务内出现异常位置多的时候...空指针, 数组越界, 类型转换, … 一个一个排查吧.
----
round four (划重点, 最常见, 隐患最多的一种写法)
这是来自一个对try catch第三次使用的 4 号选手
try {