java异常处理策略 [英] java Exception Handling strategy

问题描述

在我的代码中，我有一个应用程序，如此UI - >后端进程 - >结果到UI。使用try，catch来处理我的异常。但是在代码中，我有这么多重复的异常，可能会在不同的类中引发相同的异常。

所以，我打算做一个异常处理策略，以便当抛出异常时，它必须被重定向到单独的异常处理代码（像独立的自定义异常处理库类）。所以它不应该在我的业务逻辑内。

有人可以建议我如何实现它，以及是否最好的想法来处理我的例外？或者有人可以建议我使用异常处理技术来做这件事吗？

谢谢，期待您的回复。

解决方案

如果你抛出太低级别的异常，可以抓住他们上面的几个调用，并用用户友好的消息打包更为一般和有意义的异常，再次出现问题到最高级别，停止应用程序并以某种方式（例如标签）向用户查看。

从有效的Java（项目61 ）：

>当一个方法抛出一个没有明显的连接
到它执行的任务的异常时，这是令人不安的。这通常发生在一个方法传播一个低级别抽象抛出的
异常时。这不仅是令人不安的，而且它的
会污染具有实施细节的较高层的API。如果更高层的执行
在随后的版本中发生变化，那么它抛出
的异常也将改变，潜在地破坏现有的客户端程序。

为避免这个问题，较高的层应该捕获较低级别的异常
，并且在它们的位置抛出可以用
更高级抽象来解释的异常。这个成语被称为异常翻译：

  //异常翻译
 try {
 //使用下层抽象来做我们的出价
 ... 
} catch（LowerLevelException e）{
 throw new HigherLevelException（...）; 
} 
  

虽然异常翻译优于无意识的异常传播
从较低层，不应该过度使用。在可能的情况下，最好的
处理较低层异常的方法是通过确保
较低级别的方法成功来避免这些异常。有时您可以通过检查更高级别方法参数的有效性
，然后再将它们传递给较低的层。

如果不可能防止较低层次的异常，那么下一个最好的事情就是让更高层默认地处理这些异常，从而使较高级别的
调用者与较低级的问题保持一致。在这些情况下，
可能适当地使用一些适当的日志记录
工具（如java.util.logging）来记录异常。这允许管理员调查
的问题，同时绝对客户端代码和最终用户。

总之，如果不可能防止或处理较低
层的异常，请使用异常转换，除非较低级别的方法恰好能够保证
其所有异常都适用于较高级别。链接提供
两个世界最好的：它允许您抛出适当的更高级别的
异常，同时捕获失败分析的根本原因（项目63）。

I am working on an application where the process goes on like this UI-->backend process --> result to UI.

In my code, I have handled my exceptions using try, catch. But in the code I have so many repeated exceptions that may throw same exceptions in different classes.

So, I am planning to do a exception handling strategy so that when exception is thrown it must be redirected to the separate exception handling code (something like separate custom exception handling library class). so that it should not be inside my business logic.

Could anyone suggest me how to implement it and whether its best idea to handle my exceptions? or Could anyone suggest me an exception handling technique to do this other than mine?

Thank you, expecting your reply.

解决方案

If you throw exceptions that are too low-level catch them few calls above, and pack as more general and meaningful exception with user friendly message what went wrong, and throw them once again to highest possible level, where you stop your app and view them somehow (e.g. on label) to user.

from Effective Java (item 61):

It is disconcerting when a method throws an exception that has no apparent connection to the task that it performs. This often happens when a method propagates an exception thrown by a lower-level abstraction. Not only is this disconcerting, but it pollutes the API of the higher layer with implementation details. If the implementation of the higher layer changes in a subsequent release, the exceptions that it throws will change too, potentially breaking existing client programs.

To avoid this problem, higher layers should catch lower-level exceptions and, in their place, throw exceptions that can be explained in terms of the higher-level abstraction. This idiom is known as exception translation:

// Exception Translation
try {
   // Use lower-level abstraction to do our bidding
   ...
} catch(LowerLevelException e) {
   throw new HigherLevelException(...);
}

While exception translation is superior to mindless propagation of exceptions from lower layers, it should not be overused. Where possible, the best way to deal with exceptions from lower layers is to avoid them, by ensuring that lower-level methods succeed. Sometimes you can do this by checking the validity of the higher-level method’s parameters before passing them on to lower layers.

If it is impossible to prevent exceptions from lower layers, the next best thing is to have the higher layer silently work around these exceptions, insulating the caller of the higher-level method from lower-level problems. Under these circumstances, it may be appropriate to log the exception using some appropriate logging facility such as java.util.logging. This allows an administrator to investigate the problem, while insulating the client code and the end user from it.

In summary, if it isn’t feasible to prevent or to handle exceptions from lower layers, use exception translation, unless the lower-level method happens to guarantee that all of its exceptions are appropriate to the higher level. Chaining provides the best of both worlds: it allows you to throw an appropriate higher-level exception, while capturing the underlying cause for failure analysis (Item 63).

这篇关于java异常处理策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！