commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] concept proposal: error resort
Date Fri, 12 Dec 2003 00:30:21 GMT
I would agree, and go further to say that this concept is too far from the
JDK to be admitted into [lang].

Stephen

----- Original Message -----
From: "__matthewHawthorne" <matth@phreaker.net>
> I've played around with a similar idea before, but I ended up tossing it
>   when it became too much work to manage.
>
> When I don't like the way a certain class handles erroneous conditions,
> I usually just write a small wrapper class.  This may seem like a crude
> solution, but it's small and simple.
>
> Handling the logic of deciding what type of error to throw for each
> method just seems like a lot of work with not much gain.  I think that
> in general, error types are very specific to a class, and it's therefore
> hard to generalize it.
>
> Tomasz suggested using Aspects, which is interesting.  I'm currently in
> the process of learning this, and it seems like it could help with this
> sort of thing.
>
>
>
>
> ASHWIN Suresh wrote:
> > I would say I am still at the concept stage only, and can say
> > very little about actual implementation. That is something
> > we can do here provided the concept sounds useful.
> > We could possibly look at providing some facility like you mention,
> > rather than requiring the coder to code if-else blocks in each
> > relevant method.
> >
> >
> >>in class implementing ErrorResortInterface you'd like to 'if'/'case'
> >
> >
> > I would propose to name the interface ErrorResort, or Resortable, or
> > Erresortable.
> >
> > Ash
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Tomasz Pik [mailto:pikus@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
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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


Mime
View raw message