geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james_strac...@yahoo.co.uk>
Subject Re: [i18n] Hardcoded message strings
Date Wed, 27 Aug 2003 08:06:34 GMT

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 :)

Leaving exception messages in the code (with or without i18n) is a code 
smell IMHO. Especially when often lots of useful exception details are 
hidden in the text message, rather than being exposed as typesafe 
getters.

If developers can't be bothered to create proper exception classes for 
different kinds of exception, at the very least they could provide 
helper factory methods inside the generic Exception they want to reuse 
which can then take care of i18n.

e.g.

public class FooException extends Exception {

	public static FooException newFailedToOpenFileException(File file) {
		return new FooException("org.a.g.foo.FooException.failedToOpenFile", 
file);
	}

	public static FooException newFailedToCloseFileException(File file, 
int bar) {
		return new FooException("org.a.g.foo.FooException.failedToCloseFile", 
file, bar);
	}
}

etc.

The main aim I'm suggesting is to save littering the code with 
exception message text, i18n patterns and so forth and unify their use 
inside the Exception classes themselves. Whether there is a nice 
exception hierarchy to catch exact exceptions or there are big generic 
exceptions that serve many different purposes (which I don't personally 
like), we can still easily hide the message text & i18n inside the 
exception classes - which will make refactoring easier down the road.



>
> -dain
>
> On Tuesday, August 26, 2003, at 12:51 PM, Cabrera, Alan wrote:
>
>> Think about the ramifications of this proposal, it will lead to deep 
>> and
>> wide inheritance hierarchies for our exceptions.  Do we want this?
>>
>>
>> Regards,
>> Alan
>>
>>> -----Original Message-----
>>> From: James Strachan [mailto:james_strachan@yahoo.co.uk]
>>>
>>> Agreed with all that.
>>>
>>> My only comment is - lets try put all the messages inside the
>>> exception
>>> classes. So that in Java code we throw the exception which accurately
>>> describes what the exception is...
>>>
>>> e.g.
>>>
>>> throw new InsertOfEntityBeanFailedException(bean, sqlException,
>>> errorCode);
>>>
>>> and there's no message / text in the throws clause. Then we can
>>> refactor later to make the getLocalizedMessage() support i18n without
>>> affecting the codebase much.
>>>
>>> This also allows for fine grained exception catching too.
>>>
>>>
>>> On Tuesday, August 26, 2003, at 06:34  pm, Dain Sundstrom wrote:
>>>
>>>> Again we have the cart way ahead of the horse...
>>>>
>>>> We need to draw a line.  What are we gong to make i18 and
>>> what are we
>>>> going to leave in english.  When are we going to add i18?
>>>>
>>>> I suggest we come up with a way for us to add i18 later without any
>>>> pain now (see my previous message).  Further, I suggest we make the
>>>> rule that only user displayable messages and log messages > info
>>>> support i18, but now Exceptions, debug, or trace.
>>>>
>>>> We have a huge project in front of us and we should do everything to
>>>> make this a fast and enjoyable experience, and I find that editing
>>>> messages bundles and working with message formatter to be
>>> neither.  I
>>>> think we should take a long breath and think about a way to make it
>>>> easy add this later.


James
-------
http://radio.weblogs.com/0112098/


Mime
View raw message