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

问题描述

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

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

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

谢谢，期待您的回复。

解决方案

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

从有效的Java（项目61 ）：

当一个方法抛出一个没有
与其执行的任务的明显连接的异常时，这是令人不安的。这通常发生在
当一个方法传播一个低级
抽象抛出的异常时。这不仅令人不安，而且还通过实施细节污染了上层的API
。如果更高层的实现
在随后的版本中发生更改，则抛出的异常
也将更改，可能会破坏现有客户端
程序。

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

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

虽然异常转换优于低层异常的无意识传播，不要过度使用在
可能的情况下，处理较低层异常的最佳方式是通过确保较低级别的方法成功，
可以避免这些异常。有时候，
可以通过检查更高级别方法的
参数的有效性，然后将它们传递到较低层来实现。

如果是不可能防止较低层次的异常，那么最好的办法就是让更高层默认地处理这些
异常，从而使更高层次的方法的调用者与
的较低级别的问题隔离开来。在这种情况下，可以使用
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屋！