让我们回顾一些基本的异常设计准则，这些准则从“对象设计：角色，职责和协作”中进行了总结（Rebecca Wirfs-Brock和Alan McKean，Addison-Wesley，2003年）。

不要尝试处理编码错误。

除非在错误情况下要求您的软件采取特殊措施，否则不要花很多时间设计它来检测编程错误并从中恢复。 对于超出范围的数组索引，除以零错误或任何其他编程错误，最好的策略是快速失败（并留出可用于解决问题的审计线索）。

避免声明很多异常类。

仅当您期望对代码进行某种处理时，才根据例外类型创建新的例外类。 以我的经验，这种情况很少，并且Java API中提供的异常类可以达到目的。 每当您提高抽象级别时，就将低级异常重铸为高级别异常。

不要让实现细节作为异常从方法调用中泄漏出来。

否则，您的用户可能会认为您的软件已损坏。 当低级异常渗透到高级处理程序时，几乎没有上下文可以帮助处理程序做出明智的决定或报告可追溯到任何明显原因的条件。 每当您跨越抽象边界重播异常时，可使异常处理程序在调用链中位于较高的位置，以做出更明智的决策。 如果要在重铸问题时包含问题跟踪，则始终可以创建链接的异常。 链接的异常提供了附加的上下文，并保留了对原始较低级别异常的引用。 您可以重复链接异常。

提供上下文以及异常。

在异常处理中最重要的是有助于创建明智响应的信息。 异常类保存信息。 除了默认情况下提供的基本堆栈跟踪信息之外，您还可以将它们设计为包含其他信息。 您可能包括引发异常的参数值，特定的错误文本或对计划恢复有用的详细信息。

尽可能处理与问题接近的异常。

作为第一道防线，请考虑初始请求者。 如果呼叫者知道足够的信息来执行纠正措施，则可以当场纠正情况。 如果您在远离源的地方传播异常，则可能很难跟踪源。 通常，远离问题的对象无法做出有意义的决策。

仅将异常用于表示紧急情况。

不应引发异常以指示正常的分支条件，这些条件会改变调用代码中的流程。 例如，查找操作可能返回零，一个或多个对象，因此在这种情况下，我不会引发异常。 相反，我将设计自己的find（）方法以返回空对象或空集合。 另一方面，断开数据库连接确实是紧急情况。 无法按计划继续进行任何操作。

不要重复抛出相同的异常。

尽管在引发异常之前不花费任何费用，但经常引发异常的程序运行得更慢。

参考：来自我们的JCG合作伙伴 Sanjeev Kumar的“异常处理准则/最佳实践”，来自Architect's Diary博客。