geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [i18n] Hardcoded message strings
Date Wed, 27 Aug 2003 16:51:49 GMT

On Wednesday, August 27, 2003, at 05:26  pm, Dain Sundstrom wrote:
> On Wednesday, August 27, 2003, at 05:35 AM, Alex Blewitt wrote:
>> On Wednesday, Aug 27, 2003, at 09:06 Europe/London, James Strachan 
>> wrote:
>>> On Tuesday, August 26, 2003, at 07:13  pm, Dain Sundstrom wrote:
>>>> -1 for the reason below and I believe this type of requirement on 
>>>> programmers will lead to worse exception handling.  If a developer 
>>>> has to add a new class for every exception message, they won't 
>>>> throw exceptions.
>>> Then they're very lazy developers :)
>> Absoultely. Being a lazy developer is great; learn to make the tools 
>> work for you. In eclipse, you can say 'throw new 
>> NonExistantException()' and then the red-squiggle underline gives you 
>> a prompt to create the class...
> 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.

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


View raw message