当方法检测到其参数不正确时，我会使用很多 IllegalArgumentException 。这是任何公共方法的责任，停止处理（以避免更难以理解的间接错误）。另外，方法开头的一些 if 具有文档目的（文档永远不会偏离代码，因为它就是代码:-)）。
public void myMethod(String message, Long id) {
if (message == null) {
throw new IllegalArgumentException("myMethod's message can't be null");
// The message doesn't log the argument because we know its value, it is null.
}
if (id == null) {
throw new IllegalArgumentException("myMethod's id can't be null");
// This case is separated from the previous one for two reasons :
// 1. to output a precise message
// 2. to document clearly in the code the requirements
}
if (message.length()<12) {
throw new IllegalArgumentException("myMethod's message is too small, was '" + message + "'");
// here, we need to output the message itself,
// because it is a useful debug information.
}
}
I never throw NullPointerException. For me, it is one that appears naturally in the code when something goes wrong and that requires a developer to look at what happens. Then (s)he fixes the cause and it doesn't happen again.
I use IllegalStateException to signal that an object is incorrectly configured or that calls are in an incorrect order. However, we all know that ideally, an object should ensure it can't be in a bad state and that you can't call it in incorrect order (make a builder and a resulting object ...).
I use a lot of IllegalArgumentException when a method detects that its parameters are incorrect. This is the responsibility of any public method, to stop processing (to avoid indirect errors that are more difficult to understand). Also, a few ifs in the beginning of a method serve a documentation purpose (documentation that never diverge from the code because it is the code :-) ).
public void myMethod(String message, Long id) {
if (message == null) {
throw new IllegalArgumentException("myMethod's message can't be null");
// The message doesn't log the argument because we know its value, it is null.
}
if (id == null) {
throw new IllegalArgumentException("myMethod's id can't be null");
// This case is separated from the previous one for two reasons :
// 1. to output a precise message
// 2. to document clearly in the code the requirements
}
if (message.length()<12) {
throw new IllegalArgumentException("myMethod's message is too small, was '" + message + "'");
// here, we need to output the message itself,
// because it is a useful debug information.
}
}
I also use specific Runtime Exceptions to signal higher level exceptional conditions.
For example, if a module of my application couldn't start, I might have a ModuleNotOperationalException thrown (ideally by a generic code like an interceptor, otherwise by a specific code) when another module calls it. After that architectural decision, each module has to deal with this exception on operations that call other modules...
对此的一种违反是，有时您需要将应该是检查异常的内容包装在 RuntimeException 中，以满足接口的定义。作为一个简单的示例，您可能有一些时髦的 java.util.List 实现来管理多台计算机之间的分布式列表。显然，如果单独定义的话，这会引发受检查的异常（可能是 IOException 的某个子类），但让此类实现 List 的好处是客户端可以几乎透明地使用它，任何他们使用另一个列表的地方。
不过，这可能会导致 Joel 所说的泄漏抽象，因此您的文档非常重要清楚可以抛出什么异常以及它们的含义！在这种情况下，我发现 RuntimeException 的自定义子类通常可以更清晰地传达根本原因，而不是尝试将其硬塞到现有的运行时异常类中。
I've always considered that runtime exceptions should represent programming errors (e.g. null reference passed in when not expected, array index out of bounds, etc.) while checked exceptions should represent exceptional conditions in the environment that cannot be "coded away" (e.g. IOException, SQLException).
One violation of this is that sometimes you'll need to wrap what ought to be a checked exception in a RuntimeException, in order to satisfy the definition of an interface. As a brief example, you might have some snazzy implementation of java.util.List that manages a distributed list between multiple machines. Clearly this would throw checked exceptions (probably some subclass of IOException) if defined on its own, but the benefits of making this class implement List is that clients can use it almost transparently, anywhere they use another list.
This can lead to what Joel terms a leaky abstraction, though, so it's important that your documentation is clear what exceptions can be thrown and what they mean! In this case I find a custom subclass of RuntimeException to generally be clearer at communicating the root cause rather than trying to shoehorn it into an existing runtime exception class.
I use IllegalArgumentException relatively often. Most of the time, I will try to return the default value as soon as it is logical but some of the time it was not, and so I use this one.
Another one I use is ArrayIndexOutOfBoundsException.
Mostly I don't throw runtime exception. Rather than after checking specific conditions throw user defined exceptions. But the few I have used are - IllegalAccessException , ArithmeticException, NumberFormatException and SecurityException.
发布评论
评论（6）
我从不抛出NullPointerException。对我来说，当出现问题时，它会自然地出现在代码中，并且需要开发人员查看发生的情况。然后他（她）解决了原因，这样就不会再发生了。
我使用 IllegalStateException 来表示对象配置不正确或调用顺序不正确。然而，我们都知道，理想情况下，一个对象应该确保它不会处于错误状态，并且不能以错误的顺序调用它（创建一个构建器和一个结果对象......）。
当方法检测到其参数不正确时，我会使用很多 IllegalArgumentException 。这是任何公共方法的责任，停止处理（以避免更难以理解的间接错误）。另外，方法开头的一些
if具有文档目的（文档永远不会偏离代码，因为它就是代码:-)）。我还使用特定运行时异常来表示更高级别的异常情况。
I never throw NullPointerException. For me, it is one that appears naturally in the code when something goes wrong and that requires a developer to look at what happens. Then (s)he fixes the cause and it doesn't happen again.
I use IllegalStateException to signal that an object is incorrectly configured or that calls are in an incorrect order. However, we all know that ideally, an object should ensure it can't be in a bad state and that you can't call it in incorrect order (make a builder and a resulting object ...).
I use a lot of IllegalArgumentException when a method detects that its parameters are incorrect. This is the responsibility of any public method, to stop processing (to avoid indirect errors that are more difficult to understand). Also, a few
ifs in the beginning of a method serve a documentation purpose (documentation that never diverge from the code because it is the code :-) ).I also use specific Runtime Exceptions to signal higher level exceptional conditions.
我一直认为运行时异常应该代表编程错误（例如，意外传入的
null引用、数组索引越界等），而受检查的异常应该代表环境中无法执行的异常情况。被“编码掉”（例如IOException、SQLException）。对此的一种违反是，有时您需要将应该是检查异常的内容包装在 RuntimeException 中，以满足接口的定义。作为一个简单的示例，您可能有一些时髦的 java.util.List 实现来管理多台计算机之间的分布式列表。显然，如果单独定义的话，这会引发受检查的异常（可能是 IOException 的某个子类），但让此类实现 List 的好处是客户端可以几乎透明地使用它，任何他们使用另一个列表的地方。
不过，这可能会导致 Joel 所说的泄漏抽象，因此您的文档非常重要清楚可以抛出什么异常以及它们的含义！在这种情况下，我发现 RuntimeException 的自定义子类通常可以更清晰地传达根本原因，而不是尝试将其硬塞到现有的运行时异常类中。
I've always considered that runtime exceptions should represent programming errors (e.g.
nullreference passed in when not expected, array index out of bounds, etc.) while checked exceptions should represent exceptional conditions in the environment that cannot be "coded away" (e.g.IOException,SQLException).One violation of this is that sometimes you'll need to wrap what ought to be a checked exception in a RuntimeException, in order to satisfy the definition of an interface. As a brief example, you might have some snazzy implementation of
java.util.Listthat manages a distributed list between multiple machines. Clearly this would throw checked exceptions (probably some subclass ofIOException) if defined on its own, but the benefits of making this class implementListis that clients can use it almost transparently, anywhere they use another list.This can lead to what Joel terms a leaky abstraction, though, so it's important that your documentation is clear what exceptions can be thrown and what they mean! In this case I find a custom subclass of
RuntimeExceptionto generally be clearer at communicating the root cause rather than trying to shoehorn it into an existing runtime exception class.UnknownException，非常有用：P
我也喜欢 org.apache.commons.lang.NotImplementedException
UnknownException, very usefull :P
i also like org.apache.commons.lang.NotImplementedException
我使用
IllegalArgumentException的频率相对较高。大多数时候，我会尝试在合乎逻辑的情况下立即返回默认值，但有时却不然，所以我使用这个。我使用的另一个是 ArrayIndexOutOfBoundsException。
I use
IllegalArgumentExceptionrelatively often. Most of the time, I will try to return the default value as soon as it is logical but some of the time it was not, and so I use this one.Another one I use is
ArrayIndexOutOfBoundsException.根据 Effective Java 中的 Joshua Bloch，
最常重用的异常：
According to Joshua Bloch in Effective Java,
The most commonly reused exceptions:
大多数情况下我不会抛出运行时异常。而不是在检查特定条件后抛出用户定义的异常。但我用过的少数是 -
IllegalAccessException 、 ArithmeticException 、 NumberFormatException 和 SecurityException 。
Mostly I don't throw runtime exception. Rather than after checking specific conditions throw user defined exceptions. But the few I have used are -
IllegalAccessException , ArithmeticException, NumberFormatException and SecurityException.