只是想征求一些意见:你认为有一个拦截器类来拦截所有异常并将它们转换为特定于应用程序的异常是一个好主意吗?基本上异常处理(没有别的)从一个类移到另一个类。
您能对此提出任何优点/缺点吗?
谢谢你。
在我看来,在某些情况下它可以用来降低复杂性。我有一个带有嵌入式数据库的应用程序;我可能会丢失记录、sql 异常、各种各样的东西,我不想向我的用户报告这些。一些 UI 类有一个方法调用另一个调用的方法,等等,并且在某处一些代码运行到其中一个并开始将其传递回来。在特定于应用程序设计的适当级别,我捕获它,可能记录它,并将其包装在特定于应用程序的异常中,它的工作是生成一条消息,引导我的用户使用它做正确的事情,除了通知他出事了。特定于应用程序的异常是为将要看到结果消息的用户量身定制的,并且可以响应一堆“低级”而生成
我会说这是一个非常糟糕的主意。如果我使用的接口记录了它在某些条件下抛出 IllegalArgumentException,我希望在满足此条件时得到 IllegalArgumentException,而不是某些特定于应用程序的异常。
如果它有一个错误并且它抛出一个 NullPointerException,我更喜欢让 NullPointerException 直接识别问题,而不是让它包含在一些特定于应用程序的异常中,该异常不能说明问题是什么以及问题出在哪里。
现在,如果您的类不是 AOP 意义上的拦截器,而是另一个对象或 API 的包装器(例如 spring-jdbc 是 JDBC 的包装器),并且它仅将检查的异常转换为特定于应用程序的异常有意义方式,我不会看到任何问题。
是的,这是一个合理的想法。以 Springorg.springframework.jdbc.support.SQLExceptionTranslator
为例。它特别适合将恼人的已检查异常转换为未检查异常。
通常的缺点是增加了复杂性 - 所以这取决于您有多少特定于应用程序的异常。