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:[EMAIL PROTECTED] > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
