How to handle exceptions when writing a library (n

Question

I'm currently writing an Java Wrapper for a RESTful web services API.

I'm now trying to clean up some of the exception handling, and not sure what approach to take. This is a tool intended to be used by Java programmers, so I can't really handle it the same way I would with a end-user application.

If I have a method (connection) that contains code that could throw exceptions, how do I get those exceptions to float up to the end-programmer? and is this even the way I should handle it, depending on them to catch the exceptions? etc...

Answer 1

I suggest you catch the exceptions from the underlying API (unless they really make sense to allow through), and throw a new exception which is more appropriate for your level of abstraction.

Use exception chaining if you don't feel like discarding the cause of the exception.

Answer 2

The question is how opaque you want your library to be.

Every exception type that you throw to your users should imply the user can do something about it. For example,

catch (ConnectionException e) {
  disconnect();
  connectAgain();
}

only works if your users have access to disconnect() and connectAgain(). If, however, you promise to provide all kinds of connectivity, your code should already have this logic, and if that fails, throw a generic WrapperException and be done with it.

Possibly a good approach for you would be declaring your own type of exception (and don't make it a RuntimeException), catching the exceptions you observe and throwing your exception instead.

Answer 3

You will have to pass the exception to the user in any case since it's a library.

• If you are not logging and are not planning to create custom exceptions, then you just don't have to handle the exception.
• if you are logging, handle the exception and rethrow the exception.
• if you have custom exceptions, make sure it have take exception a constructor parameter and then link the current exception to your current exception and then throw custom exception. This is required to maintain the useful stack trace information.

Answer 4

I think you should decide whether the existing type is specific to the implementation, or inherent to the library. For example, if it's a network related exception and you're obviously making a network-based API, I'd just let it propagate up. The caller needs to be aware of that sort of error anyway.

On the other hand, if it's a database-related exception which is only possible because for some bizarre reason you're looking up the WSDL in an embedded database, or something like that, that's clearly inappropriate for the caller to have to deal with - so catch it and wrap it in an exception which is more appropriate to your abstract level.

Answer 5

I think its important what the API does, and in which context it is used.

If the API is part of your presentation/rendering layer, then I would prefer to always return something that is ready to be rendered, decorated, or written to the response stream.

If the API is meant to perform (non-rendering/UI related) processing, I would have no problem throwing up any exceptions outised the scope of the API logic.

If the API is designed well, these would be causes that are clearly beyond the control of the API, or logically beyond the scope of what the API "knows how to" or "should" handle, even if it could catch/control it.

When returning an exception to a "user" I prefer returning standard exceptions whenever possible rather than a single custom wrapper type.

Within my API implementation however, I use custom exception types frequently if they serve a clear and useful purpose.

just my 2 cents :)