aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes handling errors Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "handling errors" Watch "handling errors" New topic
Author

handling errors

Srinivas Ramgopal
Ranch Hand

Joined: Aug 06, 2006
Posts: 63
Hi all,

In case of a service development wherein the service could be called by other services in the workflow, is it okay to handle java.lang.Error and runtime exceptions inorder to handle the flow gracefully (though Sun does not recommend so, I have been reading few latest articles in web that recommend otherwise).
Thus I would like to know your views.

Thanks in advance for your valuable input and time.

Regards.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30352
    
150

Srinivas,
How would the callers of your service know that something went wrong? I would prefer to let them catch the exceptions if it is important to them.

Note that catching Error is even more dangerous than catching RuntimeException. Errors are things that hard to recover from.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I'd be inclined to catch as much as I could and throw application specific exceptions, but there are some errors that probably mean the JVM is so messed up that your attempt to throw something new won't work either.

What kind of environment are you running in? It's probably good to have some kind of service redundancy through load balancing and maybe even self healing restarts. In EJB land a service is just a thread within the container. If one dies, the container will likely start another.

In Forte 4GL (not Java) we had services that could automatically restart when they crashed and clients that could automatically retry. Crash, restart and retry could go on forever if the client is passing bad data that causes the crash, so even that has to have limits, eg only "n" retries.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
wood burning stoves
 
subject: handling errors