Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3F4D18BC.2070108@dehora.net>
Date: Wed, 27 Aug 2003 21:46:52 +0100
From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: Re: [i18n] Hardcoded message strings
References: <B7ED37E2-D8B3-11D7-9B9F-000393DB559A@coredevelopers.net>
In-Reply-To: <B7ED37E2-D8B3-11D7-9B9F-000393DB559A@coredevelopers.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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:

   http://c2.com/cgi/wiki?GeneralizeOnExceptionBehavior

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

Bill de h�ra