定义自定义异常有什么好处?

发布于 2024-10-21 03:59:03 字数 30 浏览 5 评论 0原文

在 Java 中定义客户异常有什么重要原因吗?

Any big reasons to define custome exceptions in Java?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

满地尘埃落定 2024-10-28 03:59:03

两个原因立即浮现在我的脑海中:

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

Two reasons immediately spring to mind:

  1. Simply so you don't say try { ... } catch (Exception e) { ... } - having your own subclasses lets you treat distinct exception cases separately. (Such as the difference between not having permissions to run a report, and the report execution failing).
  2. You can add extra context - so for example if you have your own AlreadyLoggedInException, say, that exception can have a method to retrieve the IP address from which the other session was started. Or an AccountLimitExceededException could contain the current account limit. Extra information in the exception allows you to potentially take a more well-informed response when catching it.
物价感观 2024-10-28 03:59:03

很简单,它可以让你以正确的方式处理每个异常。

考虑下面的代码,

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-all 可以,那么类层次结构仍然意味着您仍然可以使用 catch(Exception ex) {} 捕获所有异常。

Quite simply, it allows you to deal with each exception in the correct way.

Consider the following code

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
}

Without this, you would be left trying to do a catch-all type of exception.

If however a catch-all will do, then class hierarchy still means that you can still catch all exceptions using catch(Exception ex) {}.

如果没有 2024-10-28 03:59:03

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

Providing error-specific information, allowing more fine-grained exception handlers.

云仙小弟 2024-10-28 03:59:03

是的。最大的优点是它允许您抛出您想要的异常。如果您重用现有的异常,则捕获该异常的任何代码段都必须处理实际异常不是由您的代码引发的,而是由其他库方代码引发的可能性。这往往会使错误处理变得更加不稳定。

Yes. The big advantage is that it allows you to throw and exceptions that mean what you want them to mean. If you reuse an existing exception, any piece of your code that catches the exception has to deal with possibility that the actual exception wasn't thrown by your code, but by some other library party code. This tends to make error handling more flakey.

日裸衫吸 2024-10-28 03:59:03

通过自定义异常,您可以告诉调用者发生了特定类型的错误,而不仅仅是错误。因此,调用者可能会针对此类错误执行特定的操作。

让我们用汽车来比喻:您更喜欢您的汽车拒绝以独特的红灯闪烁启动,还是以专用的“油箱空”灯闪烁?

With a custom exception, you can tell your callers that a specific kind of error has happened, rather than just an error. And the callers may thus do sothing specific to this kind of error.

Let's use a car analogy : do you prefer your car to refuse starting with a unique red light blinking, or with a dedicated "gas tank empty" light blinking?

嗼ふ静 2024-10-28 03:59:03

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

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

In my view the main motivation for custom exceptions is to achieve a better modeling of your application domain. When designing classes you spend a great deal of effort to name objects and assign their responsibilities. I think that at this point some effort for considering possible error conditions is a good investment. For example, when digging deeper, clients can often give you some common examples that have to be handled (e.g. invalid data, violation of logical constraints, unreliable sensors, etc.). As a result you will have code that is easier to understand and modify. The application specific errors are nicely separated and the handling of additional errors can be easily achieved.

Another point is that it might provide better abstraction for different parts of the system. For example, if you really anticipate that the implementation of persistence part will change in future, then it is far better to use custom exceptions in its API. Otherwise you will have later a lot of fun dealing with SQLException or SAXExceptions in many different places :-)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文