geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill de hÓra <>
Subject Re: [i18n] Hardcoded message strings
Date Wed, 27 Aug 2003 20:46:52 GMT
Dain Sundstrom wrote:

> Back on point, I agree that we should have our own custom subclasses of 
> the spec exceptions that adds useful information.  For example in EJB we 
> should have a custom subclasses of EJBException and RemoteException, 
> GeronimoEJBLocalException and GeronimoEJBRemoteException respectively... 
> don't ask why, spec EJB exception handling just plain sucks.  These 
> should carry the application name, EJB name,  and primary key if 
> appropriate.  This does not get us i18, because standard use will be 
> something like;
> throw new GeronimoEJBLocalException(
>         "Transaction failed to commit",
>         applicationName,
>         ejbName,
>         primaryKey,
>         rootCause);

It doesn't prevent i18n either.

Anyone with an opinion on exception handling and API level 
exceptions should chew on this if they haven't already:

I think Bruce Eckel was on about checked exceptions a while back, 
but I don't have a link handy. [I also recall Ron Jeffries going 
head to head with the xp list for nearly a week asking for a good 
reason for checked exceptions; the list pretty much came up wanting]

>> However I concur that we should not be too strict on coding rules to 
>> start with - we need lots of code writing & don't wanna put folks off 
>> by being too religious about code conventions. Indeed we should be 
>> focussing on ensuring the core container, component model & deployer 
>> architecture is right so we can start filling in the J2EE stack rather 
>> than worrying too much about the exact layout of the code - we can 
>> refactor later.
> +1000000  we can refactor later

Of course, but ime it's way easier and more fun without finegrained 

Bill de hÓra

View raw message