On Tue, 2012-10-23 at 04:40, Dan Creswell wrote: > > In conclusion and being blunt, this feels like an ugly cosmetic (irony) > change that gives no value but clutters up the classname space some more. > So it doesn't make my life harder but it's a pig with lipstick on and > there's no way I'm making out with that hog. > I have to agree - when I'm dealing with an exception, I want to know why it happened, not where it came from. The fact that an exception was raised in a given package doesn't provide useful information about whether the fault is temporary or permanent, or what I should do about it. Adding a superclass exception moves us away from a faithful modeling of the problem space, which is bad. I'm hard pressed to give you an example of exactly why it's bad, but I know that software systems get more likely to fail when the logical model departs from the physical reality.
Greg. > > On 23 October 2012 09:06, Simon IJskes - QCG <[email protected]> wrote: > > > On 20-10-12 09:19, Dan Creswell wrote: > > > >> Or maybe we provide a wrapper in the distribution? > >> > >> I'm with you, my recovery strategies are easier to code with the hierarchy > >> as it is. > >> > >> > > But you don't loose anything by accepting a JiniException as starting > > point for the different exception families. > > > > What i see here, is a group of people, rejecting a modification that would > > make life easier for some, without stating how it would make life harder > > for them. > > > > What does accepting this change make life harder for you? > > > > Please specify. With code examples. > >
