Why do some APIs simply throw Exception?

Question

This year I started using several Third-Party-Libraries (all open source) and I noted that some throw exceptions in a proper way (i.e. declaring exactly which checked Exceptions can be thrown by a method in the method signature), while others just declare throws Exception, which generally makes it more difficult to catch and properly handle them. I think examples for the "good" ones are the Apache libraries (at least these I use like commons-cli), examples for the "bad" ones are WEKA and the Simple Framework XML. (All my examples are Java examples because I primarly use Java, but my question holds in general.)

So, an obvious reason for the "bad" behavior is that it is easier/faster to program and may look nicer than a throws ThisException, ThatException, AnotherException. But is this really all reason there is to it?

This is not about checked/unchecked exceptions. This is about readability and that I have to deal with an exception that simply has the basic Exception type with no clarifying information. If it would be an unchecked exception, maybe always the same, I would be very happy as long as the documention clarifies why it happened. In addition, e.g. the Simple Framework API uses special exceptions inside, but all that is propagated to the top level is "Exception".

What are the reasons for this behaviour in general?

Answer 1

There is no good reason to do this. And in fact declaring a method as throws Exception makes it difficult to use. This is covered by this "example" in the Java Language documentation tree over on StackOverflow:

• Pitfall - Throwing Throwable, Exception or RuntimeException

The short version is that if you declare a method as throws Exception, any code that calls that method must either catch (Exception ...) or have its own throws Exception clause. If you do this consequences are as follows:

• You have nullified the compiler's ability to tell you when you haven't handle specific checked exceptions.

• Someone reading your API code has no easy way to find out what checked exceptions might actually be thrown or propagated by the method.

Answer 2

I would be very happy as long as the documention clarifies why it happened. In addition, e.g. the Simple Framework API uses special exceptions inside, but all that is propagated to the top level is "Exception". What are the reasons for this behaviour in general?

Probably because whatever the exception under the hood hapenned, you can't do more than log it and pass or display to the end user parsing failed cause : [exception translated/message]. Your application can't do something specific for the specific exception that happened under the hood, the xml processing failed, end of the story, see message & stack, that's all you need.

This could be wrap up in an GenericSimpleFrameworkXmlException. It does permit you to have multiple catch, but to be honest, I almost never have one more catch that just log and rethrow because there is no more that I can do.

edit : I don't have a log/rethrow on every layer of my application, just where I think it make sense, sometimes I'll rethrow, or convert a checked one to an unchecked or the opposite if I think this is what I need.

On the very rare case I do need a specific catch, I just split the code in two try/catch block. It happens so rarely that it weight nothing in the redability of the code as a whole.

Personnaly in almost all case, I prefer to use the IllegalArgumentException, IllegalStateException... with the right message instead of making my bunch of tree of customized exception for that. This is simplier, it does the job, and I don't have headaches about naming and organazing the tree for .. pretty much nothing.

Answer 3

Exceptions, well, error handling in general is a boring thing that many devs dont want to deal with ... period.

The mere fact that so many of us live in denial regarding the possibility of error that could arise from writing code is actually central to the debate Checked vs Unchecked. You are experiencing a different aspects of the same problem.

So checked exceptions are annoying because you have to handle them in some way at each call along the call stack. True, so the solution to this for some is to just throws Exception and be done with it, or as is the case more and more especially since Java 8 to just wrap them in a RuntimeException and forget about it.

This problem is not new, before the time of exceptions we had functions that returned an error code. Yet so often have I read code where very rarely these error codes were checked in any way that it pretty much became the norm.

Having Exception as the sole type in all method signature is bad API desing period, just like throwing the same SQLException was bad desing from the folks that gave us JDBC. At the very least you know that the code CAN throw an exception and be ready for it, as opposed to not even knowing if exceptions can be thrown at all.

Answer 4

One reason for this is because the framework in question performs callbacks to user-supplied code and the framework author does not want to limit what exceptions the callback code is allowed to throw, so they simply add throws Exception to their interfaces in order to allow any possible implementation. They then need to propagate this exception out to the public interface of their own methods, because not knowing what exceptions the user might throw they can't handle them internally.