Question

I’ve dealt with instances where I would throw/rethrow an exception knowing that the code surrounding it would catch the specific exception. But is there any time you would want to throw an exception, knowing that it wouldn’t be caught?

Or at least, NOT catch an exception?

Exceptions immediately halt the application unless their handled right? So I guess I’m asking if you would ever want to purposely let your application die?

Answer 1

If your application is primarily going to be used by other clients and is not standalone, it generally makes sense to throw exceptions if a condition arises that you don’t know how to (or don’t want to) handle, and there’s no sensible way for you to recover from it. Clients should be able to decide how they want to handle any exceptions that you might throw.

On the other hand, if your application is the endpoint, throwing an exception essentially becomes a notification mechanism to alert people that something has gone terribly wrong. In such cases, you need to consider a few things:

• How important is the continued running of the application? Is this error really unrecoverable? Throwing an exception and terminating your program is not something you want to be doing on the space shuttle.

• Are you using exceptions as a proxy for real logging? There’s almost never a reason to do this; consider a real logging mechanism instead. Catch the exception and have the logger work out what happened.

• What are you trying to convey by throwing the exception yourself? Ask yourself what the value in throwing a new exception is, and consider carefully whether there isn’t a better way to do what you want.

• Not catching an exception may leave resources in a bad state. If you don’t gracefully exit, things are generally not cleaned up for you. Make sure you understand what you’re doing if you need to do this — and if you’re not going to catch it, at least consider a try-finally block so you can do some tidying up.