RE: Handling exceptions

"Stephen McConnell" <[email protected]>
Newsgroups gmane.comp.jakarta.avalon.user
Message-ID <000001c46e32$c16a8420$1601a8c0@devbox>

If the exception represents a condition whereby the component cannot
continue to function then you should just re-throw the exception.  If
this is within the constructor or a lifecycle artifact delivery
operation then Merlin will cleanup for you.  

If the error occurs as part of runtime execution then things are not so
strait-forward.  We currently don't have a mechanism whereby a component
can notify the container of an error - however, such an error handler
facility could be written (although I think some more work on the
internal event model within merlin's composition model is probably a
prerequisite).  In the meantime you would typically log the error and
cleanup internally.  When logging an error you should do something like:

   If( getLogger().isErrorEnabled() )
   {
       final String error = 
         "My deep and meaningful error message.";
       getLogger().error( error );
   }

Cheers, Steve.


-----Original Message-----
From: David Leangen [mailto:[email protected]] 
Sent: Tuesday, July 20, 2004 12:21 AM
To: [email protected]
Subject: Handling exceptions


Using Avalon is quite a different animal from what I'm used to... but I
love
it so far!

I am wondering, what is the best way to handle exceptions within a
service
provider? Should I just log the problem with a call to getLogger(), or
is
there a better way? Seems to me that simple logging the problem is not
sufficient, since this would not pass the problem up the component
chain...


Your insights would be greatly appreciated.



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.