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 17:27:22 GMT
On Wednesday, August 27, 2003, at 11:51 AM, James Strachan wrote:

> On Wednesday, August 27, 2003, at 05:26  pm, Dain Sundstrom wrote:
>> I for one hope that this idea dies right here.  There are no lazy 
>> developers here.  This is an opensource project and anyone that shows 
>> up is definitely not lazy.  We have a certain amount of effort 
>> available to us, and we can choose to use it by making developers do 
>> tedious development tasks, because one day someone might find it 
>> useful, or we can point them at exciting stuff people need today.  
>> Also, if coding on geronimo is tedious because of our development 
>> rules, very few will join us and our over all effort pool will be 
>> even smaller.
> I don't see how encouraging developers to hide exception messages 
> inside Exception classes rather than litter them through the 
> application code  makes development tedious or is particularly much 
> effort. It'll help us provide consistent exception codes or add i18n 
> later on with minimal refactoring overhead.

Funny, this is a completely different discussion...  So what are we 
talking about i18 or exception styles.  Of course the exception style 
you are suggesting makes i18 easier, but is only about 20% of the way 
to i18.

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",

>> Before we add any such rules, I think we need to thing about weather 
>> the rule is worth the effort expense and impact on our over all 
>> effort pool.
> 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


  * Dain Sundstrom
  * Partner
  * Core Developers Network

View raw message