Sidebar

• Author

  

  A software development manager adopting Scrum with XP practices.

• Pages:

• Bio

• Categories:

• acceptence testing
• automated builds
• cancer
• code reviews
• conferences
• enterprise architecture
• haskell
• jsf
• management
• organization
• podcasts
• project management
• ruby
• scheme
• scrum
• security
• soa
• software development
• test driven development
• tutorial
• Uncategorized
• websphere

• Feeds

• 

• 

• Meta:

• Log in
• Valid XHTML
• Entries RSS
• Comments RSS

• Search
• 

Main Contents

try {
  AddressEntityBean addressEntityBean = addressHome.findByCityAndStreet(city, street);
  addressEntityBean.remove()
}
catch (Exception e) {
  //this guy is already gone
}

2 Comments

1. David Hayes July 5, 2007 @ 2:21 am

   I find the usage of Exceptions troubling at times. I would hazard a guess to say that this code expects there to be an addressEntityBean most of the time, and thus performing an null pointer check seems one step too extreme, based on the odd occasion of there not being one. But at the same time, the code becomes greatly expensive if an exception is being thrown more times than expected (do you really need a full stack trace for every time there isn’t an address?).
   Besides which, “this guy” might still be there, but he just couldn’t get to the bean in the time, because he was maybe in the shower!

2. Ed Gibbs July 5, 2007 @ 5:49 am

   I just loved the classic through a generic exception and then don’t bother doing anything with it, but the comment just cracked me up.