Win a copy of Rust Web Development this week in the Other Languages forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Understanding try catch

 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
author and iconoclast
Posts: 24203
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
sure it does!

thanks for your answer

BTW: excuse my ignorance: what's a rule engine?
 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Space seems cool in the movies, but once you get out there, it is super boring. Now for a fascinating tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic