geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: [Exceptions] [i18n] Hardcoded message strings
Date Thu, 28 Aug 2003 12:33:14 GMT
On Thursday, Aug 28, 2003, at 12:31 Europe/London, Bill de hÓra wrote:

> Dain Sundstrom wrote:
>
>> Theoretical Computer Science discussions are titillating, but this is 
>> engineering.  If we go off and create a whole new exception 
>> hierarchy, we will have a massive learning curve for new coders, and 
>> we will have to come up with a hack to get our new hierarchy to play 
>> well with the spec required exception handling system.  What I am 
>> saying is we get Java and J2EE warts and all.
>
> Strong agreement. My point was that minimizing the number of new 
> checked exceptions in Geronimo should be considered. Their 
> profileration (or not) is very much an engineering matter.

There always seems to be an interesting debate about 'unchecked' versus 
'checked' exceptions. There's really no difference, bar the fact that 
(in effect) every method has 'throws RuntimeException, Error' 
automatically appended to the end of it during compile time.

One point that is definitely worth noting is that whilst having a lot 
of VerySpecificException classes is good, it's still important to have 
a message in it. It may well be a message that's provided in the 
exception's contructor, but it should be there:

public class VerySpecificException extends LessSpecificException {
   public VerySpecificException() {
     super("A very specific exception message");
   }
}

Otherwise, you can end up with a bunch of exceptions where 
e.getMessage() == null. This is a nightmare to debug in logs unless the 
type is also present.

For logging exceptions, I strongly think that the logging mechanism 
should do:

log(e.getClass() + ":" + e.getLocalizedMessage());
   or
log(e.toString())

rather than

log(e.getMessage())

Note that this applies also when chaining exceptions (and the exception 
doesn't support nesting the Throwable directly); using
   throw new MyException(other.toString())
is much better than
   throw new MyException(other.getMessage())
because it (a) will use getLocalizedMessage(), and (b) if there is no 
message it will still print out the type

Hopefully this is useful experience gained from looking through many 
WebSphere logs and problems when only exception messages are passed and 
not 'toString'

Alex.

Mime
View raw message