The concept of error resort.
<cut/>
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?
Regards, Tomek
Waiting for comments, Ash
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
