Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Understanding try catch

 
miguel lisboa
Ranch Hand
Posts: 1281
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
miguel lisboa
Ranch Hand
Posts: 1281
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sure it does!

thanks for your answer

BTW: excuse my ignorance: what's a rule engine?
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic