只是想问一些意见: 你认为有一个拦截器拦截所有异常并将它们转换为特定于应用程序的异常是一个好主意吗?基本上异常处理(没有别的)从一个类移到另一个类。
你能否就此提出任何利弊?
谢谢。
答案 0 :(得分:0)
是的,这是一个合理的想法。看一下Spring的org.springframework.jdbc.support.SQLExceptionTranslator
作为例子。将刺激性检查的异常转换为未经检查的异常特别有用。
通常的缺点是复杂性增加 - 所以它取决于你有多少特定于应用程序的例外。
答案 1 :(得分:0)
我想说这是一个非常糟糕的主意。如果我使用一个接口来记录它为某些条件抛出IllegalArgumentException,我希望如果满足这个条件就会得到IllegalArgumentException,而不是某些特定于应用程序的异常。
如果它有bug并且它抛出NullPointerException,我更喜欢直接识别问题的NullPointerException,而不是将它包含在某些特定于应用程序的异常中,这不会告诉问题是什么以及在哪里。
现在,如果您的类不是AOP意义上的拦截器,而是围绕另一个对象或API的包装器(例如spring-jdbc是JDBC的包装器),并且它只将已检查的异常转换为特定于应用程序的异常以一种有意义的方式,我不会发现任何问题。
答案 2 :(得分:0)
在我看来,它可以用来降低某些情况下的复杂性。我有一个带嵌入式数据库的应用程序;我可能会丢失记录,sql异常,所有类型的东西,我都不想向用户报告。有些UI类有一个调用另一个调用方法等的方法,某些代码会运行到其中一个代码中并开始将其重新传递回来。在适当的级别,这是特定于应用程序设计,我陷阱,可能记录它,并将其包装在一个特定于应用程序的异常中,它产生一条消息,导致我的用户用它做正确的事情,除了通知他有什么不对劲之外特定于应用程序的异常是针对将要查看结果消息的用户量身定制的,并且可以生成以响应我需要捕获但不想报告的一堆“低级”异常。