blocks|key|3161999|text|基本上，每个工作都应该有自己的例外。当您捕获异常时，您不会像通常处理对象那样区分不同的实例，因此您需要不同的子类型。使用过多的自定义异常是一种很少发生的情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3162000|一个建议是根据需要创建异常，如果很明显一种异常类型与另一种异常类型重复，则通过合并两种类型来重构代码。当然，如果从一开始就有一些想法去构造异常，这会有所帮助。但通常，对于与现有的特定情况的异常没有1:1对应关系的所有情况，都应使用自定义异常。|3162001|另一方面，NullPointerExceptions和IndexOutofBoundsExceptions实际上可能是合适的。但是，不要捕获它们(除了日志记录)，因为它们是编程错误，这意味着在抛出它们之后，程序处于未定义的状态。|offset|length|style|CODE|3162002|entityMap^0|0|0|5|K|R|P|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]|$F|Q|G|R|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

Basically, each job deserves an own exception. When you catch exceptions, you don't distinguish different instances, like you would normally do with objects, therefore you need different subtypes. Using too many custom exceptions is a case which I see hardly occurring.

One advice would be to create exceptions as needed, and if it becomes apparent that one exception type is a duplicate of another, refactor the code by merging the two. Of course it helps if some thought goes into structuring exceptions from the beginning. But generally, use custom exceptions for all cases that have no 1:1 correspondence to existing, situation-specific exceptions.

On the other hand, <code>NullPointerException</code>s and <code>IndexOutofBoundsException</code>s might actually often be appropriate. Don't catch these, though (except for logging) as they're a programming error which means that after throwing them, the program is in an undefined state.

blocks|key|365069|text|我的经验法则是，当客户端(调用者)可能合理地想要做一些不同的事情时，根据抛出的异常类型，额外的异常类型是必要的。然而，通常不需要额外的异常类型。例如，如果调用者编写的代码如下|type|unstyled|depth|inlineStyleRanges|entityRanges|data|365070|try+{
+++++doIt();
}+catch+(ExceptionType1+ex1)+{
+++++//+do+something+useful
}+catch+(ExceptionType2+ex2)+{
+++++//+do+the+exact+same+useful+thing+that+was+done+in+the+block+above
}|code-block|syntax|javascript|365071|那么显然就不需要额外的异常类型了。我经常看到(或被迫编写)这样的代码，因为被调用的代码在创建新的异常类型时过于热衷。|365072|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

My rule of thumb is when the client (the caller) might reasonably want to do something different, depending on the type of exception thrown, the additional exception types are warranted. More often than not, however, the extra exception types are not needed. For instance, if the caller is writing code like

<pre><code>try {
 doIt();
} catch (ExceptionType1 ex1) {
 // do something useful
} catch (ExceptionType2 ex2) {
 // do the exact same useful thing that was done in the block above
}
</code></pre>

then clearly the additional exception types are not needed. All too often I see (or am forced to write) code like this because the code being called was overzealous in its creation of new exception types.

blocks|key|366521|text|The+Java+Specialists写了一篇关于Exceptions+in+Java的文章，其中列出了一些创建异常的“最佳实践”，总结如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|366522|366523|不要编写自己的异常(+Java+API中已经有很多有用的异常)|unordered-list-item|366524|编写有用的异常(如果您必须编写自己的异常，请确保它们提供了有关所发生问题的有用信息)|366525|366526|entityMap|0|LINK|mutability|MUTABLE|url|http://www.javaspecialists.eu/|1|http://www.javaspecialists.eu/archive/Issue162.html^0|0|K|0|Q|I|1|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]|$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|12|8|@]|9|@]|C|$]]|$1|H|3|I|5|G|7|13|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|14|8|@]|9|@]|C|$]]|$1|K|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]|S|$5|N|O|P|C|$Q|T]]]]

<a href="http://www.javaspecialists.eu/" rel="noreferrer">The Java Specialists</a> wrote a post about <a href="http://www.javaspecialists.eu/archive/Issue162.html" rel="noreferrer">Exceptions in Java</a>, and in it they list a few "best practices" for creating Exceptions, summarized below:

<ul>
<li>Don't Write Own Exceptions (there are lots of useful Exceptions that are already part of the Java API)</li>
<li>Write Useful Exceptions (if you have to write your own Exceptions, make sure they provide useful information about the problem that occurred)</li>
</ul>

blocks|key|3374879|text|如果我找不到一个名称来描述所导致的错误类型的异常，那么我会创建自己的异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3374880|这是我的原则--大拇指。|3374881|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If I can't find an exception that has a name describing what type of error was caused then I make my own.

That's my rule-o-thumb.

blocks|key|366539|text|我自己的经验法则：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|366540|我从不抛出异常，除非在单元测试中抛出的东西是无关紧要的，并且没有理由在上面花费任何额外的时间。|366541|我为我的自定义业务逻辑中发生的错误创建了自己的自定义异常类型。此异常类型尽可能多地用于重新转换其他异常，除非客户端有必要了解实际发生的情况。|366542|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

My own rule of thumb:

I never throw Exception, except in unit tests when what you throw is irrelevant and theres no reason to spend any extra time on it.

I create my own custom exception type for errors occuring in my custom business logic. This exception type is used as much as possible for recasting other exceptions, except in cases where it makes sense for the client to have visibility into what actually occurred.

blocks|key|365103|text|不要做我公司的开发人员所做的事情。有人创造了一个类似于java.lang.IllegalArgumentException的sic+InvalidArguementException，我们现在(字面上)在成百上千的类中使用它。这两种方法都表示向方法传递了非法或不适当的参数。说到浪费。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|365104|Joshua+Bloch在《Effective+Java+Programming+Language+Guide》一书中介绍了这一点，我的首选是最佳实践第八章。Exceptions第42条:支持使用标准异常。这是他说的一小段话，|offset|length|style|BOLD|365105|365106|重用预先存在的异常有几个好处。其中最重要的是，它使你的应用编程接口更容易学习和使用，因为它符合程序员已经熟悉的既定约定我的重点，而不是布洛赫的。紧随其后的是，使用你的应用编程接口的程序更容易阅读，因为它们不会充斥着不熟悉的异常。最后，更少的异常类意味着更小的内存占用和更少的加载类时间。|blockquote|365107|365108|最常重用的异常是IllegalArgumentException。当调用者传入一个值不合适的参数时，通常会抛出这个异常。例如，如果调用方在表示某个操作要重复的次数的参数中传递了一个负数，则会抛出此异常。|365109|365110|也就是说，你应该永远不要抛出异常()本身。Java有一组精心选择的、多样化的、目标明确的内置异常，它们涵盖了大多数情况。和对发生的异常进行了足够好的描述，以便您可以对原因进行补救。|365111|对将来需要维护你的代码的程序员要友好。|365112|entityMap^0|0|23|E|0|0|0|0|0|0|1O|1|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|10|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|14|8|@$D|15|E|16|F|G]]|9|@]|A|$]]|$1|R|3|S|5|6|7|17|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|U|$]]

Don't do what the developers at my company did. Somebody created an [sic] InvalidArguementException that parallels java.lang.IllegalArgumentException, and we now use it in (literally) hundreds of classes. Both indicate that a method has been passed an illegal or inappropriate argument. Talk about a waste...

Joshua Bloch covers this in Effective Java Programming Language Guide [my bible of first resort on Best Practices] Chapter 8. Exceptions Item 42: Favor the use of standard exceptions. Here's a bit of what he says,

<blockquote>
 Reusing preexisting exceptions has several benefits. Chief among these, it makes your API easier to learn and use because it matches established conventions with which programmers are already familiar [my emphasis, not Bloch's]. A close second is that programs using your API are easier to read because they aren't cluttered with unfamiliar exceptions. Finally, fewer exception classes mean a smaller memory footprint and less time spent loading classes.
 
 The most commonly reused exception is IllegalArgumentException. This is generally the exception to throw when the caller passes in an argument whose value is inappropriate. For example, this would be the exception to throw if the caller passed a negative number in a parameter representing the number of times some action were to be repeated.
</blockquote>

That said, you should never throw Exception itself. Java has a well-chosen, diverse and well-targeted bunch of built-in exceptions that cover most situations AND describe the exception that occurred well enough so that you can remedy the cause.

Be friendly to the programmers who have to maintain your code in the future.

blocks|key|3374943|text|在创建您自己的异常时：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3374944|如果要编写由句柄或声明规则自动强制执行的受控异常，则需要扩展要编写运行时可执行项的Exception+Class|offset|length|3374945|If，则需要扩展运行时异常类。|unordered-list-item|3374946|所有异常必须是运行时异常的子类。|3374947|3374948|3374949|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html^0|0|15|F|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@$D|W|E|X|1|Y]]|A|$]]|$1|F|3|G|5|H|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|10|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

While creating your own exception:

<ul>
<li>All exceptions must be a child of the <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html" rel="nofollow">Throwable Class</a></li>
<li>If you want to write a checked exception that is automatically enforced by the Handle or Declare Rule, you need to extend the <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Exception.html" rel="nofollow">Exception Class</a></li>
<li>If you want to write a runtime execption, you need to extend the Runtime Exception Class.</li>
</ul>

blocks|key|366582|text|不要吃异常，抛出https://stackoverflow.com/a/921583/1097600|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|366583|避免创建自己的异常。使用下面已经存在的工具。|366584|IllegalStateException
UnsupportedOperationException
IllegalArgumentException
NoSuchElementException
NullPointerException|code-block|syntax|javascript|366585|抛出未检查的异常。|366586|示例|366587|public+void+validate(MyObject+myObjectInstance)+{
++++if+(!myObjectList.contains(myObjectInstance))
++++++++throw+new+NoSuchElementException("object+not+present+in+list");
}|366588|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/921583/1097600^0|8|16|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|C|$]]|$1|O|3|P|5|H|7|16|8|@]|9|@]|C|$I|J]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]]]

<h3>Don't eat exceptions, throw them <a href="https://stackoverflow.com/a/921583/1097600">https://stackoverflow.com/a/921583/1097600</a></h3>

Avoid creating your own exception. Use the below ones that are already there.

<pre><code>IllegalStateException
UnsupportedOperationException
IllegalArgumentException
NoSuchElementException
NullPointerException
</code></pre>

Throw unchecked exceptions.

<h3>Example</h3>

<pre><code>public void validate(MyObject myObjectInstance) {
 if (!myObjectList.contains(myObjectInstance))
 throw new NoSuchElementException("object not present in list");
}
</code></pre>

I have been in both situations: 

<ul>
<li>Creating too many custom Exceptions</li>
<li>Using too many general Exception class</li>
</ul>

In both cases the project started OK but soon became an overhead to maintain (and refactor).

So what is the best practice regarding the creation of your own Exception classes?

What is the general rule of thumbs for creating an Exception in Java?

单元测试

Java

这两种情况我都经历过：创建太多自定义ExceptionsUsing太多常规异常类在这两种情况下，项目一开始都不错，但很快就成为了维护(和重构)的开销。那么，关于创建您自己的异常类的最佳实践是什么？

问在Java中创建异常的一般经验法则是什么？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Java中创建异常的一般经验法则是什么？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在Java中创建异常的一般经验法则是什么？
EN