3

I am currently refactoring an existing codebase (EJBs) to rip out all blocks where a Throwable is caught inside of the EJB.

try {
    ... do some business logic
} catch(Throwable t){
    ... log and swallow ... :-(
}

I want/need to convince the people around me with proper documentation that "catching Throwable" is a no-go for an EJB (we have lots of discussions around this). Weblogic will handle all the "Error" conditions and maybe invalidate EJBs and put fresh (working) EJBs into the pool. Catching Throwable would undermine all these security nets provided by weblogic, and catching Throwable is bad practice anyway (but people here are reluctant and use the "Throwable" hammer everywhere).

Is anyone able to point me to some online docs where this behaviour is explained (for weblogic, jboss, etc.). I searched via Google and had a look at the weblogic docs but wasn't able to find anything, just generic java doc.

Captain Man
  • 6,997
  • 6
  • 48
  • 74
Marcel
  • 710
  • 8
  • 23

2 Answers2

4

  1. Buy a copy of Effective Java, Second Edition by Joshua Bloch for every member of your team.

  2. Have everyone read Chapter 9, "Exceptions", which covers:

    • "Use exceptions only for exceptional conditions"
    • "Use checked exceptions for recoverable conditions and runtime exceptions for programming errors"
    • "Avoid unnecessary use of checked exceptions"
    • "Favor the use of standard exceptions"
    • "Throw exceptions appropriate to the abstraction"
    • "Document all exceptions thrown by each method"
    • "Include failure-capture information in detail messages"
    • "Strive for failure atomicity"
    • "Don't ignore exceptions"
matt b
  • 138,234
  • 66
  • 282
  • 345
  • While this is sound advice, I think his question was about proving that Weblogic will invalidate session EJBs when their methods throw uncaught exceptions. – Sean Owen May 10 '10 at 15:20
  • matt b, thanks for your quick reply. i have the copy of the book ;-). i need some doc in the context of app servers (like weblogic). especially that EJB code should not catch "Errors" like OutOfMemoryError etc.. And how appservers treat these error conditions. i want to rip all the bad throwable error handling out. but people can't be easily convinced here. hope you know what i mean. cheers – Marcel May 10 '10 at 15:25
  • well, it's arguable and accepted that no code beyond the top-layer should ever be catching Errors - certainly doing so in EJB layers (or servlet layers, or DAO layers, etc) is a bad practice. – matt b May 10 '10 at 15:41
  • cheers guys, i guess the best is really to throw them the pudding into the face.... thanks for your help but anyway some weblogic doc would still be appreciated ;-) – Marcel May 10 '10 at 15:57
2

They say, the proof is in the pudding.

Write a small example that does nothing but throw different kinds of exceptions ( Runtime, Errors ) and demonstrate that your container gracefully handles them.

This will stop the critics dead in their tracks.

Alexander Pogrebnyak
  • 44,836
  • 10
  • 105
  • 121