You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/09/02 00:48:40 UTC
RE: Useful error messages
> So I did some digging .....
> .. and in the James source for RepositoryManager I noticed the following:
We inherited that code from Cornerstone when we were told that in order to
fix bugs in the Cornerstone code, we needed to take that into our module so
that PeterD could remove it from Avalon. Unfortunately, I don't think that
anyone on our side has really looked at it much.
(a) we would be happy to give it back to you.
(b) we would be happy for some suggestion(s).
> catch( final Exception e )
> {
> final String message = "Cannot find or init repository: " +
e.getMessage();
> getLogger().warn( message, e );
> throw new ServiceException("", message, e );
> }
Probably someone wanted to get the exception into that component's log, and
also to notify the caller.
> in AvalonMailStore (which is actually the "JamesMailStore") we have
> the following fragment
> catch (Exception e) {
> if (getLogger().isWarnEnabled()) {
> getLogger().warn( "Exception while creating repository:" +
e.getMessage(), e );
> }
> e.printStackTrace();
> throw new ServiceException("","Cannot find or init repository", e);
> }
> As a rule I NEVER log an exception AND throw it. The only time
> you need to log an exception is when you don't intent to throw it.
The printStackTrace ought to be canned, along with (almost) all uses of
RuntimeException. We recently cleaned up a bunch of the latter.
The logging pattern is still an issue. Logging to the component's log
and/or throwing the exception. The former is reporting, the latter is
functional. The latter *must* be done, so we are back to the issue of
wanting the exception to be logged in the right log.
> Finally, onto some Avalon concerns.
> (a) configuration exceptions would be more useful if they contained
> the offending fragment
> (b) better specs are needed about component/container seperation
> of responsibilities (e.g. who handled error reporting)
There is still the issue of locality, although this would not be apparent if
you only had one log file.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Useful error messages
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>So I did some digging .....
>>.. and in the James source for RepositoryManager I noticed the following:
>>
>>
>
>We inherited that code from Cornerstone when we were told that in order to
>fix bugs in the Cornerstone code, we needed to take that into our module so
>that PeterD could remove it from Avalon. Unfortunately, I don't think that
>anyone on our side has really looked at it much.
>
> (a) we would be happy to give it back to you.
> (b) we would be happy for some suggestion(s).
>
>
I have not idea what giving this back would imply - what I am more than
happy to do is to work though the james code and cleanup sources of
multiple logging directives.
>
>
>>catch( final Exception e )
>>{
>>final String message = "Cannot find or init repository: " +
>>e.getMessage();
>>
>>
>>getLogger().warn( message, e );
>>throw new ServiceException("", message, e );
>>}
>>
>>
>
>Probably someone wanted to get the exception into that component's log, and
>also to notify the caller.
>
>
That's my guess as well.
>
>
>>in AvalonMailStore (which is actually the "JamesMailStore") we have
>>the following fragment
>>
>>
>
>
>
>>catch (Exception e) {
>> if (getLogger().isWarnEnabled()) {
>> getLogger().warn( "Exception while creating repository:" +
>>
>>
>e.getMessage(), e );
>
>
>> }
>> e.printStackTrace();
>> throw new ServiceException("","Cannot find or init repository", e);
>>}
>>
>>
>
>
>
>>As a rule I NEVER log an exception AND throw it. The only time
>>you need to log an exception is when you don't intent to throw it.
>>
>>
>
>The printStackTrace ought to be canned, along with (almost) all uses of
>RuntimeException. We recently cleaned up a bunch of the latter.
>
When I spot this sort of thing I could go ahead and make the change -
but to be honest I've been hesitating because I'm not totally into the
James code base and there is always this little angel on my sholder
saying "maybe your missing something". Well, I think I'll tell the angel
to take a little holiday and I'll start committing some updates.
>The logging pattern is still an issue. Logging to the component's log
>and/or throwing the exception. The former is reporting, the latter is
>functional. The latter *must* be done, so we are back to the issue of
>wanting the exception to be logged in the right log.
>
>
This is something that I don't have a clear answer on (which bugs me).
We have a situation where a decision in the code is taken relative to an
assumption that the devoper is making about the actions of the
assembler. This is one of these situations where there is a qualifiable
conflict of interest and the problem is that you cannot mediate because
the parties are never there at the same time. I'm getting a headache
already.
>
>
>>Finally, onto some Avalon concerns.
>>
>>
>
>
>
>>(a) configuration exceptions would be more useful if they contained
>> the offending fragment
>>(b) better specs are needed about component/container seperation
>> of responsibilities (e.g. who handled error reporting)
>>
>>
>
>There is still the issue of locality, although this would not be apparent if
>you only had one log file.
>
>
This is not (or at least should not be) a container concern - it is (or
should be) an assembler concern (i.e. an assembler should control the
log life configuration which in this case includes the assignment of
logging channels to logging targets). I.e. the container has (or should
have) only one logging target - the logging system manager. A log
system manager (under the control of the a systems manager or assembler)
would be responsible for any breakout of different targets.
General comment - having implemented a container, one of the real PITA^3
subjects is handling the bootstrap logging.
Cheers, Steve.
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org