geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [i18n] Hardcoded message strings
Date Wed, 27 Aug 2003 21:48:30 GMT
On Wednesday, August 27, 2003, at 03:46 PM, Bill de hÓra wrote:

> 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.

That is my point exactly; this is a completely different issue.  It 
neither helps or hurts.  The example I gave was simple, but don't get 
me wrong the integration of a parameterized message into the message 
above is not trivial.  Some will argue that it is simple because the 
extra information are the provided parameters, but that is a simple 
view of the world.  Some parameters may not be used in the exception 
message and some exception message parameters are not interesting and 
should not be exposed via getters and setters.

> 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]

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.


  * Dain Sundstrom
  * Partner
  * Core Developers Network

View raw message