The moose likes Java in General and the fly likes Exception handling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Exception handling" Watch "Exception handling" New topic

Exception handling

Gavi Raaghav
Ranch Hand

Joined: Apr 28, 2005
Posts: 82
Is the following piece of exception hnadling correct or should the method signature should specify throws ProblemComunicatingWithEJBException as well along with BaseException.ProblemComunicatingWithEJBException extends BaseException.

public void advanceMeetingAgenda(MeetingVoteInstructionDetails aVoteInstruction)
throws BaseException
LogMessage logMessage =
new LogMessage(
"Entering advanceMeetingAgenda");

((AgendaServiceEJB) this.ejbSession).advanceMeetingAgenda(
catch (RemoteException remoteException)
throw new ProblemComunicatingWithEJBException(
Makarand Parab
Ranch Hand

Joined: Dec 10, 2004
Posts: 121
Looking at your exception design, it looks fine.

Makarand Parab.
Satish Chilukuri
Ranch Hand

Joined: Jun 23, 2005
Posts: 266
In my opinion, it is better to declare the specific exception in the throws clause. That way the code which calls your method will know that a communication related exception can occur and can handle the situation accordingly.
Stuart Ash
Ranch Hand

Joined: Oct 07, 2005
Posts: 637
To get the latest understanding about, after several years of its use in the Java language, read, and the discussion that is hyperlinked at the end of the page.

This throws some light on the problems in Java exceptions, and might help you understand them better.

ASCII silly question, Get a silly ANSI.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
As an experiment in working without checked exceptions, I made a rule in a largish home project that no public method can throw a checked exception. Instead they catch anything that happens inside the class and throw an application exception extended from RunTime. This worked beautifully for this project because almost all exceptions abort the user request and bubble up to a top level controller. It might not for any other project.

If you're going to have checked exceptions, there was some discussion a bove about whether to throw specific exceptions related to the error or generalized excpetions. This all depends on your contract with the caller.

For example I have a DataStore in one project that can save to flat files, database, or in-memory for testing. The DataStore interface doesn't declare throwing SQL exceptions because the storage might not even be SQL. Tomorrow I might make a DataStore implementation using JMS messages to another server, and I can't anticipate what exceptions that might throw. So I force the DataStore to throw only generic "error storing data" exceptions.

On the catching end, I catch Exception all the time. There's no need to catch distinct exception types unless you're really going to do something different about them. If we wanted to say on exception X do a retry and on exception Y give up then we have to catch X and Y separately. That kind of logic has been quite rare for me.

Hope that helps!

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
I agree. Here's the link:
subject: Exception handling
It's not a secret anymore!