何时可以使用业务逻辑的异常处理？ [英] When is it OK to use exception handling for business logic?

问题描述

我认为，作为一个通用规则，在Java（以及任何有异常处理的语言）中，应该尽量避免使用异常处理来实际处理业务逻辑。一般来说，如果预期某种情况应该发生，那么应该检查它并且更直接地处理它，而不是依赖异常处理来做检查。例如，以下不被视为良好做法：

I think it is accepted that as a general rule in Java (and perhaps any language with exception handling) one should try to avoid using exception handling to actually handle business logic. In general, if it is expected that a certain situation is supposed to happen, one should check for it and handle it more directly than relying on exception handling to do the checking for you. For example, the following is not considered good practice:

try{
  _map.put(myKey, myValue);
} catch(NullPointerException e){
  _map = new HashMap<String, String>();
}

相反，延迟初始化应该更像这样：

Instead lazy initialization should be accomplished more like this:

if(_map == null){
  _map = new HashMap<String, String>();
}
_map.put(myKey, myValue);

当然，比简单的处理延迟初始化可能有更复杂的逻辑。所以假设这种类型的东西通常是被皱眉...，如果有的话，这是一个好主意，依赖于发生的某些业务逻辑发生的异常？是否准确地说，任何一个感觉被迫使用这种方法的实例真的突出了所使用的API的弱点？

Of course there could be far more complex logic than simply handling lazy initialization. So given that this type of thing is usually frowned upon...when, if ever, is it a good idea to rely on an exception happening for certain business logic to occur? Would it be accurate to say that any instance where one feels compelled to use this approach is really highlighting a weakness of the API being used?

推荐答案

如果您依赖于某种外部API来解析数据，并且该API提供解析方法，但没有什么可以告诉是否可以解析给定的输入（或者解析是否成功取决于您的控制因素，但是API不提供适当的函数调用），并且解析方法抛出

Say, if you are relying on an external API of some sort to parse data, and that API offers parse methods but nothing to tell whether a given input can be parsed or not (or if whether the parse can succeed or not depends on factors out of your control, but the API doesn't provide appropriate function calls), and the parsing method throws an exception when the input cannot be parsed.

使用正确设计的API，它应该归因于范围几乎从不到从不 。

我完全看不到使用异常处理作为代码中正常流控制的手段的理由。它很昂贵，很难读（只看你自己的第一个例子;我意识到它可能写的很快，但是当 _map 没有被初始化，你结束up是一个空的地图，抛弃你试图添加的条目），并且它大量无用的try-catch块，它可以很好地隐藏真实的问题的代码。再次举个例子，如果调用 _map.add（）会抛出一个 NullPointerException null 突然，你默默地重新创建一个空的地图，而不是添加一个条目。我确定我真的不必说可以导致在代码中完全不相关的地方的任何数量的错误，因为意想不到的状态...

I can see absolutely no reason to use exception handling as a means of normal flow control in code. It's expensive, it's hard to read (just look at your own first example; I realize it was probably written very quickly, but when _map hasn't been initialized, what you end up with is an empty map, throwing away the entry you were trying to add), and it litters the code with largely useless try-catch blocks, which can very well hide real problems. Again taking your own example, what if the call to _map.add() were to throw a NullPointerException for some reason other than _map being null? Suddenly, you are silently recreating an empty map rather than adding an entry to it. Which I'm sure I don't really have to say can lead to any number of bugs in completely unrelated places in the code because of unexpected state...

Edit：为了清楚，上面的答案是在Java的上下文中编写的。其他语言可能（并且显然是）在异常的实现费用上有所不同，但其他方面应该仍然成立。

Just to be clear, the above answer is written in the context of Java. Other languages may (and apparently, do) differ in the implementation expense of exceptions, but other points should still hold.

这篇关于何时可以使用业务逻辑的异常处理？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！