异常处理遇到过的那些坑

今年有个目标之一就是提高团队代码的质量，因此时常会思索如何把这件事作到更好，不想教条主义，也不想搞出一个代码规范，强制团队照着作，落地的效果很差，反而把你们的积极性给弄没了。因此个人原则是，咱们一块儿看看什么事是咱们不能作的，排除掉，剩下的就是咱们能够作的，同时真正搞清楚问题在哪里，而不是简单的模仿。从我我的的经验看，代码优化中最重要的一点就是对异常状况的处理。今天，我就借这个话题，谈谈如何来优化咱们的代码。

坑1：捕捉异常不作处理

以下段代码所示，不知道各位在自家的代码中见过多少，我是指望你们不要碰见。且不说printStackTrace()这样的代码就不该该出线在正式的上线代码中，不作处理自己这会致使业务的潜在问题被隐藏了，因此这个坑是我认为异常处理中最糟糕的一点。

try

{

....

}

catch(Exception ex)
{

ex.printStackTrace();

System.out.println(XXX);

}

对于异常的捕捉处理，遵循如下的流程：

1. 处理该异常，执行具体的逻辑处理，加上必要的系统日志记录 （log4j，logcat ...）。

2. 涉及其余系统或者上一级系统，须要转换成对应的消息通知相关系统。上一级是前端，须要转换成前端能够“读懂”的错误提示。

3. 没法处理该异常或者该异常须要上一级统一处理，Throw out该异常。

坑2：不处理资源释放

仍是见代码说话，若是append出错，那么IO流就不会被关掉，那么最终就会致使整个程序由于溢出崩掉。

FileWriter fileWriter = null;

try

{

fileWriter = new FileWriter("");

fileWriter.append(item.toString());

fileWriter.close();

}

catch (IOException e)

{

...

}

在使用文件、IO流、数据库链接等不会自动释放的资源时，应该在使用完毕后立刻将其关闭。关闭资源的代码try...catch...finally的finally内执行，不然就可能由于Exception的缘由形成资源没法释放。

坑3：对异常不进行分类处理

代码中，最容易看到的一种状况就是设定catch的异常类型是Exception, 而且只有一套处理逻辑, 以下：

try{

...

}

catch (Exception e){

...

}

这里的问题主要有如下两点：

1. catch的不一样Exception，可能须要执行不一样的处理逻辑，一个catch要同时处理全部逻辑就很难实现。

2. 因为是捕捉的基类Exception, 那么RuntimeException也会被捕捉到，若是稍微不注意的话，RuntimeException最终没有任何实际处理，代码中的真正错误被掩盖掉了。

因此，正确的作法应该是按照具体的异常进行分类处理, 例如：

try{

...

}

catch (FileNotFoundException e){

// alert that the specified file

// does not exist

}

catch (EOFException e){

// alert that the end of the file

// was reached

}

catch (ObjectStreamException e){

// alert that the file is corrupted

}

catch (IOException e){

// alert that some other I/O

// error occurred

}

坑4：将大段代码放进一个Try-Catch中

　　有时能够看到，一些代码的做者巴不得把整个函数里的实现代码都放入单个try中，缘由就在于为了图省事，不肯花时间分析一大块代码中哪几行代码会抛出什么异常、异常的具体类型是什么，应该如何处理。这样的作法致使异常发生后，后续调试找问题更麻烦，一大段代码中有太多的地方可能抛出Exception。这样的作法致使，很难去统计和判断要catch哪一些类型的Exception, 只能写一个粗糙的Exception, 又掉进咱们说的第3个坑里。

一点总结

在和你们一块儿分析了上面的异常坑后，若是将来咱们想避免踩进一个异常坑，编写异常代码能够遵循如下三个点：

1. 出了什么错?

2. 在哪出的错?

3. 为何出错?

扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上如下二维码便可