Should I declare all exceptions emanating from a method in the method signature, or just a superclass of exceptions?
When I throw checked exceptions from a method, should I just declare the superclass of exceptions in the signature of the method, or all different types? If I have the following exceptions:
private class SuperException extends Exception {
}
private class SubExceptionOne extends SuperException {
}
private class SubExceptionTwo extends SuperException {
}
If the method signature is:
void confirmAccount() throws SubExceptionOne, SubExceptionTwo;
or
void confirmAccount() throws SuperException;
In the last method signature, how do you tell other developers what exceptions can be thrown from a method? If different subtypes require different processing?
source to share
The interface should be as stable as possible. So, probably Super. Many libraries use the "Super" strategy because exception specifications are much more of a maintainability annoyance than the readability or security they add. Even IOException is super that almost all Java library code uses instead of declaring more specific exceptions. (But when they declare more specific exceptions, that's because the contract is that more general IOExceptions won't be thrown.)
You can specify Sub1 and Sub2 if you really want to say that each of these exceptions can be thrown, but you don't mean to say that any derivative of Super can be thrown. Perhaps Sub1 is a NumberCrunchException, and your method calls crunchNumbers (), and users of your method can rest assured that this is the only exceptional thing your method is doing. In this case, a specific strategy is better.
source to share
If different subtypes need different handling, then definitely declare two different exceptions. Never expect the developer using your method to guess that you are actually throwing different types of exceptions.
If you are declaring two great exceptions and the user knows from the Javadoc that they are in fact descendants of the same class, the user can select them with catch (SuperException e)
or with two separate catch exceptions. But it depends on the user's choice.
Unless you declare them separately, your IDE will not add the corresponding @Throws
Javadoc to your comment. So your Javadoc will only indicate what you throw SuperException
, which will leave the user in the dark. Solving this by simply putting it in the comment text is not a real solution. If any tool uses reflection to determine what your method has chosen, it will not see individual exceptions in the array returned from Method.getExceptionTypes()
.
If the functions expected from different exceptions are more or less the same and it's just a matter of how they appear in the logs, it might be better to just use the parent exception with different messages.
source to share
The proposal throws
should convey useful information to the caller about what might go wrong when that method is called. This means that how specific you are will depend on how much information you want to convey; and that will be application dependent.
For example, an ad throws Exception
is almost always a bad idea: the information it conveys is simply “something might go wrong,” which is too vague to be useful. But whether the call needs the exact information classes in the sentence throws
is something you need to decide by looking at your program. No answer.
source to share