我一直在更新现有的库以抛出异常,以帮助改善使用该库的人员的调试.
起初,我认为我会定义特定于每个类的异常,但事实证明,大多数异常只是现有运行时异常(例如FooNegativeIntArgumentException extends IllegalArgumentException,FooNullBarException extends NullPointerException)与特定消息的扩展.
定义新例外与使用现有例外的权衡有何不同?有没有任何惯例/最佳做法?
此外,鉴于需要向后兼容性,这些异常中的大多数(如果不是全部)都是运行时异常.
Gre*_*ech 15
这是我对为什么我们有不同类型的异常以及何时创建自定义异常类型的注意事项(注意:这使用.NET类型作为示例,但相同的原则适用于Java和任何其他使用结构化错误处理的语言).在这里发布完整答案可能太长了,所以我将发布两个关键摘录.
何时抛出不同类型的异常?为每个可以以不同方式编程处理的症状抛出不同类型的异常.
何时创建自定义异常类型?当您需要使用其他信息对异常进行批注时,可以创建自定义异常类型,以帮助对代码进行编程处理.
在您的情况下,听起来您的自定义异常类型不会填补使用标准异常可以传达的症状的空白,并且它们不会为编程处理添加任何其他信息,因此不要创建它们.只需使用标准的.
扩展异常而不添加任何这样的值是完全浪费时间并且导致最好避免的持续维护成本.
使用标准例外.
这并不是说您不应该使用自定义异常,而不是在您提供的用例中.
此外,在创建自定义异常时,它们应该与导致它们的条件相关,而不是与它们可能抛出的类相关.可以将它们与业务/功能区域相关联,因为导致异常的错误条件可能以这种方式相关,并且它将提供有用的过滤技术.
您应该支持使用标准异常,并使用涵盖您所描述的未经检查的异常的Java平台库集.重用例外具有以下好处:
使您的API更易于学习和使用,因为它符合程序员已经熟悉的既定惯例
更少的异常类意味着更小的内存占用和更少的加载类所花费的时间.
| 归档时间: |
|
| 查看次数: |
3144 次 |
| 最近记录: |