如何真正的处理捕获到的异常？

Question

看了很多书 谈到异常处理这块时，都似乎没讲清楚，还是我真正没看懂?另外，网上那些培训机构的视频也是很扯，在有的例子地方，有异常就直接“抛出”...只关心所谓的“逻辑”...
也看了很多程序员写的东西，有异常就直接打印 异常堆栈信息... 
try{
   //todo something
}
catch (Exception e){
   e.printStatckTrace();  //直接打印异常信息
}
这个在开发时候调试可以，真正产品上线时候，这样写的话，无意就很低劣了。至少说明程序员在捕获异常后不知道如何处理，只是简单的打印出来. 但是这个是“处理异常”吗？ 我觉得不是吧.昨天看Bruce Eckel的JAVA编程思想中的一书，我也没找到答案。 他的一些sample代码中 要么也是方法抛出异常丢给调用者处理...然后我觉得有用的一种方法就是将异常捕获后 然后包装成运行时异常....有没有高手来真正解答一些 在捕获异常后如何“真正的处理” 而不是简单的打印异常堆栈信息？？

Answer 1

异常本来就是一个程序分支, 不要被一个特殊的名字捣迷糊了..比如:
public float division(int dividend, int divisor) {
  if(divisor == 0) {
    //要处理除数为0的情况
  }
}public float division(int dividend, int divisor) throws ZeroDivisorException {
  if(divisor == 0) throw ZeroDivisorException;
  正常处理.
}也不要期望所有的异常情况都在自己的程序中处理掉, 把异常交给调用的程序员处理也是有道理的, 因为, 你不可能知道程序的多种输出, 对用户程序员意味着什么...

Answer 2

try - catch - finally
一般来说要看你的异常是什么，才能决定怎么处理。大概分这么几种情况1. 当日志看的，
那么就是print出来，挺好的，比如WebSphere等，log里面经常都是异常，异常可以确定很多信息。
已经事发地点，这很重要啊，难道不抛吗？2. 异常作为系统分层的设计目标之一。
比如你的软件有这样两个层，一个是底层的通信，一个是上层的网络事件。
下面的异常往往体现为很难读懂的信息，而且不是上层需要关注的，上面只要知道下面网络出了毛病就OK了。
你把这种异常抛到上面，也没有意义往往异常被catch住后，再抛个上层的异常，或者错误。
3. 当逻辑分支用，不只是if，switch有分支能力，try-catch也有，只是这种做法被很多人诟病，特别是我这种从C学过来的。不喜欢把异常当成是喜事看的。但是有些系统用异常来表达某种分支，然后来处理
比如httpclient爬人家网站，爬错误了，也得继续爬啊，你只要当else处理一下就OK了，设置个标志位什么的，就完事了。不必不依不饶的。4. 异常出来了，大多数的finally也救不活的能救活的话，这个世界可真美好了。

Answer 3

一般记log的比较多，正规一些~

Answer 4

开发时什么错误都直接打出，方便修改代码和调试。
成品时有错误写入日志文件。如果是需要获取处理的错误，再错误用恢复就可以了。比如如果读取一个文件的函数，报文件不存在的错误。可以返回个错误代码，在页面用messagebox显示给用户看（指定的文件不存在，请创建什么的）。不同的错误处理起来时不同的。有些比如很小很无关紧要的错误。甚至捕获了可以不处理。

Answer 5

要分runtime和checked来处理。RuntimeException不需要处理，这个是由于程序代码本身的问题造成的，是不允许的异常，页面显示出错给客户看就行了，记录到日志方便下次修改BUG。举个的例子：
计算某业务增长率的代码：return (thisYear / lastYear * 100%);
当去年没有该项业务的时候显然会报异常，这个是由于程序员疏忽造成的，是不允许出现的异常，出现了也不要处理了，处理了也没用。自定义的CheckedException是必须要处理的，这类异常系统是预料到会出现的，是允许的异常，一般要提示用户该错误信息和建议重新操作。举个例子：
比如说登录密码错误就是：难道还不允许输错密码吗，显然需要处理返回重新登录