[lang] concept proposal: error resort

["Ash .." <eq...@hotmail.com>]

The concept of error resort.

I have in mind a concept, which if you find useful,
could perhaps find a place in the core packages
we are setting up around the use of Java.

This concerns the response of a class to known erroneous
conditions.

Taking the scenario of fetching a value,
as an example, typically there are two possible
responses, when something goes wrong: either return null
or throw an exception.

When one tries to fetch a property using ResourceBundle,
a MissingResourceException is thrown if the property is
not found, whereas the class java.lang.Properties behaves
differently (returns null.)

My idea is to introduce a concept whereby the client (user
of a class/API) is given the choice to determine the response
of the class used, to known erroneous conditions (provided,
of course, it makes sense to give this choice to the user.)

I call this Error Resort: the ability to change what behavior
a class resorts to, on known erroneous conditions.

My idea for implementing this is as follows:

A core package, such as lang, will define an interface
which has a method like:

setErrorResort(int 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.

Waiting for comments,
Ash








---------------------------------------------

Run, rabbit run.
Dig that hole, forget the sun,
And when at last the work is done
Don't sit down it's time to dig another one.

_________________________________________________________________
Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [lang] concept proposal: error resort

[Tomasz Pik <pi...@ais.pl>]

On 2003-12-11 19:44, Ash .. wrote:

> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org