Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

I am a newbie programmer and I recently started learning about exception handling in Java.

I know what try, catch and finally blocks do, but I really need to understand how to use them well and where to handle something in the call stack...

I have a project right now that involves I/O and all I'm doing is handling the exception in the lowest possible method in the call stack.

I'm sure my exception handling can be improved, so I'm asking you guys how you think of exception handling?

How did you guys get good at this and how can I better wrap my head around this idea?

share|improve this question

marked as duplicate by Joris Timmermans, Jalayn, Kilian Foth, gnat, Doc Brown Apr 30 '13 at 15:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

There is loads of similar questions on SO, pick from them. See also Throws or try-catch. – Péter Török Feb 17 '11 at 13:24
Show us some sample code and we can more easily point out any weaknesses. – Woot4Moo Feb 17 '11 at 13:58

Uncaught exceptions are for external problem management, caught exceptions for internal

In general, caught exceptions (in your try-catch-finally block) are for problems that your application can do something about. Uncaught, or runtime, exceptions are for problems that are outside the scope of your application to fix by itself (null pointer, database connection failure and so on). Typically a runtime exception is indicating a weakness in your system that an admin or a developer has to address.

When to choose a uncaught exception

Choose a runtime exception when you know that no-one further up the call stack is going to be able to recover without a retry.

"The database connection is borked. This application is not going to be able to restart it since it'll have been provided by JNDI. This application should stop attempting database access right now."

When to choose a caught exception

Choose a caught exception when you know that recovery is possible with a bit of data manipulation from the caller.

"Hey, I got a ParseException, guess I'll add in the time field since it was missing. Should've checked that beforehand..."

Overall, try to stick with the well-defined exceptions already in the language (less code to share around and explain). Understand why they are caught or uncaught. If you absolutely must create your own exception then try to keep the number of variations down and make it helpful in reporting exactly what went wrong. Consider backup up your exception with a detailed log entry if you can.

share|improve this answer
To add, you may want to catch exceptions you cannot fix if you wish to inform the user in some meaningful way. – Glenn Nelson Feb 17 '11 at 20:28
caught+caught, no uncaught? – user1249 Feb 18 '11 at 0:10
@Thorbjørn Good spot - word blindness on my part. – Gary Rowe Feb 18 '11 at 10:13

I asked a question about exception handling architecture on stackoverflow. there is a wealth of info in the answers.

Especially this article is great

The answers might not be what somebody who is calling himself a n00b is looking for. So more basic links include:

Hope this helps

share|improve this answer

Not a direct answer but a good practice - make sure that when you catch and exception and throw another exception, you pass the original exception as an argument to the new one. Java can maintain useful chains of "caused by", and it's very easy to break those chains by just throwing a completely new exception.

share|improve this answer

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