2011-03-09 36 views

回答

9

两个原因立即映入脑海:

  1. 简单,所以你不说try { ... } catch (Exception e) { ... } - 拥有自己的子类可以分别处理不同的异常情况。 (如没有权限运行报表和报表执行失败之间的区别)。
  2. 您可以添加额外的上下文 - 例如,如果您有自己的AlreadyLoggedInException,例如,该异常可以有一种方法来检索其他会话启动的IP地址。或者AccountLimitExceededException可能包含当前帐户限制。异常中的额外信息可让您在捕捉异常时采取更有效的反应。
+1

请问您可以给出一个工作示例,以便它对我变得更加清楚? – Deepak 2011-03-09 12:38:46

1

提供错误特定信息,允许更多细粒度的异常处理程序。

1

是的。最大的好处是它可以让你抛出异常,这意味着你想要的是。如果您重复使用现有的异常,则任何捕获异常的代码都必须处理实际异常不是由您的代码引发的可能性,而是由其他库代码引发的可能性。这往往会使错误处理更加灵活。

0

使用自定义异常,您可以告诉您的调用者发生了特定类型的错误,而不仅仅是错误。因此,来电者可能会特别喜欢这种错误。

让我们用一个汽车的比喻:你喜欢你的汽车拒绝以独特的红灯闪烁开始,还是专用的“燃气罐空”灯闪烁?

+1

我知道你想说什么,但谈论消息并不是一个好的比喻。如果它只是消息,那么我们都可以'抛出新的异常(“我不会开始,因为我没油了)' – 2011-03-09 11:11:31

+0

你说得对。与往常一样,汽车的比喻不是一个很好的类比。我会编辑我的文章,以避免谈论消息。 – 2011-03-09 11:20:29

2

非常简单,它允许您以正确的方式处理每个异常。

考虑下面的代码

try { 
    doSomethingThatCouldThrowManyExceptions(); 

} 
catch (ExceptionalCircumstance1 ex) { 
    // deal with this specific circumstance 
} 
catch (ExceptionalCircumstance2 ex) { 
    // deal with this specific circumstance 
} 
catch (ExceptionalCircumstance3 ex) { 
    // deal with this specific circumstance 
} 
finally { 
    // do some common code 
} 

没有这一点,你会留下试图做一个包罗万象的异常类型。

但是,如果一切顺利,类层次结构仍然意味着您仍然可以使用catch(Exception ex) {}捕获所有异常。

+0

您可能希望将类重命名为ExceptionalCircumstance2和ExceptionalCircumstance3 ;-) – perdian 2011-03-09 11:15:38

+0

好点!复制并粘贴反模式再次获胜。 – Codemwnci 2011-03-09 12:04:51

0

在我看来,自定义异常的主要动机是实现更好的应用程序域建模。在设计课程时,您会花费大量精力来命名对象并分配其职责。我认为在这一点上考虑可能的错误条件是一项很好的投资。例如,当深入挖掘时,客户通常会给你一些必须处理的常见示例(例如无效数据,违反逻辑限制,不可靠传感器等)。因此,您将拥有更易于理解和修改的代码。应用程序特定的错误可以很好地分离,并且可以轻松实现处理其他错误。

另一点是它可能为系统的不同部分提供更好的抽象。例如,如果您确实预期持续性部分的实现将在未来发生变化,那么在其API中使用自定义异常要好得多。否则,您将在以后很多乐趣处理许多不同地方的SQLException或SAXExceptions :-)