关于异常处理的规范值
下面是我们web架构下的异常处理规范，大家讨论讨论：1.定义SystemException，RuntimeSystemException，MessageException，NoErrorException
所有业务逻辑代码都只允许new以上几种异常和NullPointException，如果一定要new其它异常，请在注释中详细说明理由，注释在15汉字以上。
MessageException向用户提供一个友好信息，创建MessageException时传入两个信息，一是面对用户的友好信息，二是后台信息，后台信息必须包含详细的错误信息已帮助以后定位错误。
NoErrorException为喜欢这样写代码的人提供方便throw new NoErrorException（"用户名密码错误"）；
2.关于资源的关闭，这个我就不码字了，地球人都知道的规范。其中数据库资源和事务提交汇滚由架构同一处理，业务代码只负责声名事务。任何情况下不允许业务模块自己维护数据库资源。如果确实需要自己提交事务或回滚事务，请在注释中说明理由，理由在15汉字以上。
3.一般情况下不允许吃掉异常。或者将异常直接throws出去，或者catch后作相应的处理再throw出异常，throw出新异常时任何情况下不允许中断异常链，异常最后由系统架构表示层的最外层统一处理。如果确实有必要吃掉异常，请在注释中写明理由，理由在15汉字以上。嵌套在finally块和catch块中的异常处理吃掉异常可以不写注释，任何情况下不允许在finally块中抛出异常。
4.一般以下两种情况可以吃掉异常：（1）不可能产生的异常，如：try{ "aa".getBytes（"GBK"）；}catch（UnsupportedEncodingException ex）{ //由于部署的环境GBK编码肯定存在，不可能产生异常MyExceptionHandle.getInstance（）。logException（ex）；}
这种情况要求把异常记录，万一真的环境不支持GBK编码，也可以马上知道怎么回事
（2）不影响整体逻辑完成的局部逻辑，如：try{ sendMessage（）；}catch（Exception ex）{ //消息发送失败不影响过程的完成，不应该因此而中断过程MyExceptionHandle.getInstance（）。logException（ex）；}
这种情况要求把异常记录，以便于知道错误的存在和查找错误的原因
其它吃掉异常的情况一般也要求记录异常，如果确实不应该记录异常，请在注释中说明理由，在15汉字以上。
5.在适当的地方为异常补充更详尽的错误信息，以方便以后定位错误的原因，如：
for（……）
{ String recordId = ……
try { updateRecord（recordId）；} catch（XXXException ex）
{ throw new SystemException（"更新记录错误，记录ID为：" recordId，ex）；}以后当异常发生时，可以快速定位到发生错误的记录，方便查找原因。
（这一条很难执行，基本上靠coder的rp）
6.有必要的话，在适当的位置将异常转化为MessageException，向用户显示友好信息。
（这一条也不好评审）
7.任何情况下不允许向表示层抛出IOException，因为当客户端与服务器连接中断时，会产生IOException，这个异常不是我们所关注的，为了区分，不允许逻辑代码向表示层抛出IOException
8.表示层最外层收到异常后作如下处理：IOException忽略MessageException，向用户提示相应信息，并记录异常NoErrorException，向用户提示相应信息，不记录异常其它异常，向用户提示默认错误信息（如操作失败），记录异常异常记录时，除了记录异常的信息，时间，异常链以外，同时记录客户端IP，登录用户ID（如果有的话），request的queryString，方便以后确定产生错误的场景。
——也许，为了能够正常的说话，苏格拉底应该假装得更加无知。
页:
[1]