Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception handling

 
Gavi Raaghav
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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(
LoggingManager.DEBUG,
this.getClass().toString(),
"advanceMeetingAgenda",
"Entering advanceMeetingAgenda");

LoggingManager.log(logMessage);
try
{
((AgendaServiceEJB) this.ejbSession).advanceMeetingAgenda(
aVoteInstruction);
}
catch (RemoteException remoteException)
{
LoggingManager.log(logMessage);
throw new ProblemComunicatingWithEJBException(
CLASS_NAME,
"advanceMeetingAgenda",
remoteException.getMessage(),
remoteException);
}
}
 
Makarand Parab
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking at your exception design, it looks fine.

Regards
Makarand Parab.
 
Satish Chilukuri
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 637
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To get the latest understanding about, after several years of its use in the Java language, read http://www.mindview.net/Etc/Discussions/CheckedExceptions, 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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic