Leo Simons wrote:
Stephen McConnell wrote:
Finally, onto some Avalon concerns.
Two points:
(a) configuration exceptions would be more useful if they contained the offending fragment
indeed. Howard's HiveMind solves this beautifully: it reports the filename and line number for any config error. I expect its trivial in hivemind to expand on that information to get some surrounding context.
I suggest we add the following to ConfigurationException
final Configuration m_fragment;
public ConfigurationException( String message, Configuration fragment )
{
m_fragment = fragment;
}With this little addition, exception handling utilities can do a lot more to report and present information linked to a configuration related error. Unless anyone objects I'll go ahead and update framework and test things out.
(b) better specs are needed about component/container seperation of responsibilities (e.g. who handled error reporting)
specs? Why specs? How about some general guidelines?
Because guidelines without specs are for wimps.
Ok - guideline are helpful - but only when you have concrete knowledge and that's where a spec comes into play. The spec states what a container is obliged to do with respect to something like a component lifecycle processing exception. A guideline can drawn upon this knowledge and present recommendations to developers as to how they can best manage their interaction on the the component/container boundary.
"Log then rethrow at any containment boundary"
A server logs details of an internal exception, then sends on less detailed information to the client. A servlet applications logs details of an internal exception, then sends on less detailed information to the servlet container.
That's the general rule.
Why?
The container can provide comprehensive error management - why push this onto the component?
However, it makes sense to offload log management towards the container in an IoC application. If/when you do that, you should trust the container to do logging properly for you.
Which is where the notion of a specification comes into play.
More concretely, anytime you throw an exception from any lifecycle method that is an subclass of CascadingException and/or CascadingThrowable,
In Merlin its a class with a getCause() method. (i.e. just a touch less locked in on Avalon APIs).
and you provide the "cause" of the exception, do not log that cause seperately, it will be done for you. If you do not provide the "cause" when rethrowing, *do* log the cause but not the rest:
catch( SomeException se ) { getLog().error( "whoops", se ); throw new ServiceException( "some.thing" ); } or catch( SomeException se ) { throw new ServiceException( "some.thing", se ); } not // will print a stacktrace twice with any worthwile // logger catch( SomeException se ) { getLog().error( "whoops", se ); throw new ServiceException( "some.thing", se ); } nor // will print a stacktrace trice with any worthwile // logger catch( SomeException se ) { getLog().error( "whoops", se ); se.printStackTrace(); throw new ServiceException( "some.thing", se ); }
Yep.
with non-lifecycle methods, things are a bit different. You *may* be crossing an application boundary; depends on your component granularity. If you have
interface RequestHandler { Response handle( Request request ) throws RequestException; }
I will bet you that you will often not want to return the cause of the RequestException. So here you always have
catch( SomeException se ) { // record specifics with this component getLog().error( "whoops", se );
// rethrow a more generic exception; don't give // clients information about the internals of the // implementation throw new RequestException( 500 ); }
Which suggests that the component is taking on some management decisions - which happens to be the case in the James example (in fact James is doing component deployment itself inside the deployment by the hosting container which complicates things somewhat). But, something worth taking into consideration is the potential for category management. For example in Merlin exception report is provided under the kernel logging categrogoy because its a deployment failure. An alternative approach couild be log this information under the logging category assigned to the compoent type manager (as distinct from the channel that the James component was logging to). All this means is that we have a lot of scope with respect to where we place information and that this can be translated into useful information using support tools.
All this is hardly avalon-specific. There's several books that deal with the generic issue. I believe Ceki wrote a nice one (that I haven't read though).
all IMHO.
cheers!
Steve.
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
