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?

  • 2
    @gnat I think not. I do not want to know pro/cons about checked/unchecked Exception but specific/unspecific Exception, especially since I often have to mask the generic Exception from the API to tell it apart from other exceptions that might come up.
    – GreenThor
    Commented Nov 30, 2016 at 12:35
  • I see, the way you explain this in comments seems to be different from duplicate target. Consider editing the question to clarify that for readers (many tend to ignore comments) because as currently written, it really looks like a duplicate to me
    – gnat
    Commented Nov 30, 2016 at 12:42
  • 1
    @gnat I noticed the possibly-duplicate-heading after answering to you, just edited, thanks anyway :)
    – GreenThor
    Commented Nov 30, 2016 at 12:46
  • 1
    Related question about a language that apparently forces the equivalent of throws Exception: stackoverflow.com/questions/40718542/…
    – 8bittree
    Commented Nov 30, 2016 at 16:01
  • @8bittree really interesting. To think that this was a careful thought-through design decision surprises me. For other readers: It is explained here: github.com/apple/swift/blob/master/docs/…
    – GreenThor
    Commented Dec 1, 2016 at 8:09

4 Answers 4


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:

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.

  • 2
    you haven't handle specific checked exceptions 99.99% of my exception are handled by a LOGGER.log + a throw in a wrapped exception. Wheter the api used throw me an exception or a custom one. And because I handle almost all my exception the same, I have no interest knowing what kind of exception the API can throw to me.
    – Walfrat
    Commented Nov 30, 2016 at 14:29
  • @Walfrat - You do that by catching Exception and logging? What about all of the unchecked exceptions that you are (accidentally?) catching that way too? Any way, what you do in your own code is your own business, but if you put throws Exception into a library API you are forcing everyone else to do this. That makes the API "not fit for purpose".
    – Stephen C
    Commented Dec 1, 2016 at 6:40
  • Well if the library make me catch Exception, yes I'll catch everything, I didn't meant I use always catch(Exception e), neither that all my method throws Exception. As I said, in the specific case of the XML parsing library, if the parsing failed, it failed, weither it's because of a NumberFormatException or a checked exception it has no importance. So it makes sense to force the user of that API to catch the failing of the parsing, whatever the exception happened inside the library.
    – Walfrat
    Commented Dec 1, 2016 at 8:31
  • OK. So maybe throws Exception isn't bad for you because you deal with all of your exceptions the same way by design. Most people don't do that. Most applications require something different to that.
    – Stephen C
    Commented Dec 1, 2016 at 23:04
  • I'm doing mostly Web application + Java integration. In 8 years programming with Exceptions, Most applications required mostly to translate the exception to an end user's message, no more. I didn't saw that much others kinds of usage (meaning there is but rarely). I do know that it can be usefull to handle specifically some types of exception, but I just disagree with the Most applications from my experience, not only what I developped, but what I red too. Maybe it just a matter of fields ...
    – Walfrat
    Commented Dec 2, 2016 at 8:35

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.

  • I often read about people using the log-rethrow pattern and I avoid it, following advice from this site javacodegeeks.com/2011/01/… . I think logging is very style dependent, so personally I would refrain from doing it like you. Actually, the by far most common case I use rethrows is when I have to wrap Exception from a 3-party-API.
    – GreenThor
    Commented Dec 1, 2016 at 8:00
  • @GreenThor it's not like I catch/rethrow on every layer of my application, I do it where I think it suits. Sometimes I catch and rethrpow the same exception, sometimes I convert a check exception to unchecked or the opposite. It's all depend to what it suits, and the library that I use. If I don't agree with the library throwing a checked exception where I use it, I will wrap it in a unchecked one. That doesn't mean that library is poorly design or my code either on that specific point. It's just a matter of usage.
    – Walfrat
    Commented Dec 1, 2016 at 8:28
  • Oh sorry, I misunderstood you. Thanks for your clarification.
    – GreenThor
    Commented Dec 1, 2016 at 10:31

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.


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.

  • What do you mean by "user-supplied code"? That people contribute by coding parts of the projects for free? So throws Exception would be a way for the designer to raise willingness to contribute and implement own ideas of what could go wrong instead of "enforcing" coding discipline or allowing the possibility to exist that the designer may oversaw a potential exception and has to make corrections to the code?
    – GreenThor
    Commented Dec 1, 2016 at 8:07
  • No, I mean that the framework has interfaces that the application developer implements in order to customize the framework's behaviour for the application. Those interfaces have throws Exception on their methods in order to allow the application to throw any exception they want, and those exceptions are then propagated back to the application for handling. See, for instance, the Transform interface in Simple Framework, used to allow custom serialization of attributes. Commented Dec 3, 2016 at 16:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.