• 异常处理的原则


    这篇文章是我看到讲异常处理最好的一篇文章http://www.objectsource.com/j2eechapters/Ch18-Exception_Handling.htm。强烈建议阅读。

    以下该文内容的精粹。

    1. 异常处理基础
         1.1 System.out.println是高代价的。调用System.out.println会降低系统吞吐量。

         1.2 在生产环境中别用异常的printStackTrace()方法。printStackTrace默认会把调用的堆栈打印到控制台上,在生产环境中访问控制台是不现实的。

    2. 异常处理基本原则
         2.1 如果你不能处理异常,不要捕获该异常。

         2.2 如果要捕获,应在离异常源近的地方捕获它。

         2.3 不要吞没你捕获的异常。
         *(就是捕获的异常,但是什么也不做)

         2.4 除非你要重新抛出异常,否则把它log起来。

         2.5 当一个异常被重新包装,然后重新抛出的时候,不要打印statck trace。

         2.6 用自定义的异常类,不要每次需要抛出异常的时候都抛出java.lang.Exception。方法的调用者可以通过throws知道有哪些异常需要处理--所以它是自我描述的。

         2.7 如果你编写业务逻辑,对于终端用户无法修复的错误,系统应该抛出非检查的异常(unchecked exception);如果你编写一个第三方的包给其他的开发人员用,对于不可修复的错误要用需要检查的异常(checked exception)。

        2.8 绝对不要因为写throws语句会让你用起来不舒服,而不声明需要检查的异常。

        2.9 应用级别的错误或不可修复的系统异常用非检查的异常(unchecked exception)抛出。
        *(注意是错误,意味着不可修复,比如配置文件错误)

        2.10 根据异常的粒度组织你的方法


    P.S 关于自定义自己的异常类,我发现很多人加一个exception的包,这样作其实是不好的,异常不是业务逻辑的一部分,不应该在独立的包里。我们可以参考许多开源的框架比如Spring等,它们是没有把异常放到一个包里面的。需要注意的是hibernate有个exception的包,但是它不是用来存放异常的,而是放处理异常逻辑的类的。
  • 相关阅读:
    [转]大型网站架构设计的体系演变
    [转]木桶理论已死,长板理论告诉你:优势才是王道!
    UHF RFID编码之TPP编码
    Git使用笔记
    使用Open Live Writer写博客
    频谱分析仪
    相位噪声
    峰值因子,峰均比,Reference Level
    SeeSharpTools.JXI.DSP.Spectrum 使用
    dyld: Library not loaded: /usr/lib/libstdc++.6.dylib
  • 原文地址:https://www.cnblogs.com/cando/p/2319590.html
Copyright © 2020-2023  润新知