commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomasz Pik <>
Subject Re: [lang] concept proposal: error resort
Date Thu, 11 Dec 2003 22:33:52 GMT
On 2003-12-11 19:44, Ash .. wrote:

> The concept of error resort.


> A core package, such as lang, will define an interface
> which has a method like:
> setErrorResort(int CONSTANT);

ErrorResortType extends Enum...

setErrorResort(ErrorResortType CONSTANT);


> with constants such as THROW_EXCEPTION, RETURN_NULL, etc
> defined in the interface and passable to this method.
> Any class offering the facility of Error Resort will implement
> this interface and support the method. We could perhaps have
> other convenience classes to facilitate implementation or the like.
> But the concept is that, certain classes can choose (rather, their 
> creators)
> to give the choice of error resort to the users of that class, while
> hitherto such a thing has always been defined in the class in
> an iron-clad manner.
> The idea came to me when I was using ResourceBundle and I wished it
> returned null instead of throwing the exception when the key is
> not found. Whether in this case it makes sense or not,
> I am throwing this idea for debate, and it would be good if a useful
> addition can be made to the core library here.

Maybe I'm missing something but it looks for me that in every method
in class implementing ErrorResortInterface you'd like to 'if'/'case'
supplied 'constant' and based on this return nonexisting value
as null or throwing exception.
I'm worry that this makes code a little longer...
Something like a proxy over implementation, changing behaviour
of some methods?
Then you may 'package' every implementation that you know the behaviour
(one like Properties, one like ResourceBundle) in the way that your
proxy implement. Aspects? HiveMind?


> Waiting for comments,
> Ash

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message