File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Beginning Java and the fly likes Understanding try catch Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Understanding try catch" Watch "Understanding try catch" New topic

Understanding try catch

miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
this post continues this conversation

i remember reading elsewhere that one should catch an exception as soon as possible (possibly to get rid of that responsability as fast as one could);
but here i understand David's view.

So, after all, can i say there's no best practice for when catching an exception?

java amateur
Ernest Friedman-Hill
author and iconoclast

Joined: Jul 08, 2003
Posts: 24199

There's no single answer, that's true. In some cases, it's best to catch an exception right away, and in other cases it's best to let it propagate; in still other cases, it's best to catch it and re-throw it as another type.

If you think about an exception as a "message in a bottle", if you call a method and it throws an exception, who is that message for? If it's for you, you should catch it. If it's not, then you shouldn't.

An example: imagine you're writing a method sendMailMessage(String address, String text). It's supposed to send an email message to a given address. sendMailMessage() might open several files to get configuration information (the sender's signature, for example.) If there are file I/O exceptions while opening these files, sendMailMessage() should probabably catch them and continue on with its task, simply leaving off the signature, or using a default JavaMail configuration. The original caller doesn't really care -- it just wants the message to go through.

On the other hand, if sendMailMessage() makes the call to JavaMail to actually send the message, and JavaMail throws an exception that signifies the message couldn't be sent, well, sendMailMessage() should definitely let that one propagate (or rethrow its own wrapper exception.) This "message in a bottle" is definitely of interest to the original caller.

Make sense?

[Jess in Action][AskingGoodQuestions]
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
sure it does!

thanks for your answer

BTW: excuse my ignorance: what's a rule engine?
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
In my DAOs using Hibernate via Spring, even though Spring wraps the Hibernate exceptions in unchecked versions, I still catch a few that the DAO callers are likely to care about handling -- unlike connection closed or a configuration error -- and wrap them with my own unchecked DaoException subclasses: UniqueKeyViolatedException and ObjectNotFoundException.

The other thing I mentioned is that JUnit is already set up to make exception handling easy during testing. Unless you're specifically testing for the presence or absense of a particular exception, let it propagate from the test method. JUnit will catch it and report it as an error separate from a failure. Failures are things you test for that fail. Errors are for unexpected problems not under test.
I agree. Here's the link:
subject: Understanding try catch
jQuery in Action, 3rd edition