建议：在细节消息中包含能捕获失败的信息。

    当程序由于未被捕获的异常而失败的时候，系统会自动的打印出该异常的堆栈轨迹。在盾战轨迹中包含该异常的字符串表示法，即他的toString方法的调用结果。他通常包含该异常的类名，紧随其后的是细节消息。通常，这只是程序员或者域服务人员（指检查软件失败的人）在调查软件失败原因时必须检查的信息。如果失败的情形不容易重现，要想获得更多的信息会非常困难，甚至是不可能的。因此，异常类型的toString方法应该尽可能多的返回有关失败原因的信息，这一点特别重要。换句话说，异常的细节消息应该捕获住失败，便于以后分析。
    为了捕获失败，异常的细节信息应该包含所有“对该异常有贡献”的参数和域的值。每一种情形都代表了不同的问题，如果程序员知道应该去查找那种错我u，就可以极大的加速诊断过程。
    虽然在异常的细节消息中包含所有相关的“硬数据（hard data）”是非常重要的，但是包含大量的描述信息往往没有什么意义。堆栈轨迹的用途是与源文件结合起来进行分析，他通常包含抛出该异常的确切文件和行数，以及堆栈中所有其他方法调用所在的文件和行数。关于失败的冗长描述信息通常是不必要的，这些信息可以通过阅读源代码而获得。
    异常的细节消息不应该与“用户层次的错误信息”混为一谈，后者对于最终用户而言必须是可理解的。与用户层次的错误消息不同，异常的字符串表示法主要是让程序员或者域服务人员用来分析失败的原因。因此，信息的内容比可理解性要重要得多。
    为了确保在异常的细节信息中包含足够的能捕获失败的信息，一种办法是在异常的构造器而不是字符串细节消息中引入这些消息。然后，有了这些信息，只要把他们放到消息描述中，就可以自动产生细节消息。
    遗憾的是，Java平台类库并没有广泛的使用这种做法，但是，这种做法仍然值得大力推荐。他使程序员更加易于抛出异常以捕获失败。实际上，这种做法使程序员不像捕获失败都难！这种做法可以有效地把代码集中起来放在异常类中，由这些代码对异常类自身中的异常产生高质量的细节消息，而不是要求类的每个用户都多余的产生细节信息。
    为异常的“失败捕获”信息提供一些访问方法是合适的提供一些访问方法是合适的。提供这样的访问方法对于受检的异常，比对于未受检的异常更为重要，因为失败——捕获信息对于从失败中恢复是非常有用的。程序员希望通过程序的手段来访问未受检异常的细节，这很少见（尽管也是可以想象得到的）。然而，即使对于未受检的异常，作为一般原则提供这些访问方法也是明智的。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91342 人正在系统学习中

来源：孤芳不自賞