+1 Agreed
On Thu, Oct 18, 2012 at 2:02 PM, Dan Creswell <[email protected]> wrote: > +1 > > I've been trying to put this into words for a while, Greg hit's the mark > for me where I couldn't... > > On 18 October 2012 16:20, Greg Trasuk <[email protected]> wrote: > >> >> To be specific, you're talking about (for example) making >> TransactionException and LeaseException, and have them both extend >> RiverException. I don't like this idea for a number of reasons: >> >> First, as an old-time Jini-er, I still cling to the idea of Jini as a >> set of standards, and River as an implementation of those standards. We >> often talk about this division informally as "the API" or "the Specs", >> and "the implementation". So I don't like the idea of the name 'River' >> bubbling through the API layer. >> >> But to be clear, I still wouldn't like it if we defined a >> "JiniException". >> >> I'm probably not going to express my concerns very well - it's more of a >> "code smell" sort of thing. A better architect than me would probably >> know the exact name for the API design principle involved, but it seems >> like we're mixing the problem domain and the solution domain, where the >> exception hierarchy should mostly reflect the problem domain. >> >> Specifically, to use the exceptions I mentioned above: LeaseException >> and TransactionException don't have any commonality or relationship in >> the problem domain, except that they are both exceptions. They are >> products of two separate specifications that address different and >> orthogonal aspects of the distributed programming problem space. To >> give them a common ancestor in RiverException would be imposing the >> solution-side concept that they happen to both be defined in the same >> Apache project. To me, that doesn't seem like good API design. >> >> I'm all for reasonable exception hierarchy. For example, LeaseException >> is the parent of LeaseDeniedException, LeaseMapException, and >> UnknownLeaseException, which makes sense, since they're all types of >> exceptions involved in leasing. Similaryly, TransactionException is the >> superclass of CannotAbortException, CannorCommitException, >> CannotJoinException , CannotNest Exception, TimeoutExpiredException, >> etc, which also makes sense, because they are all types of exceptions >> that have to do with transactions. >> >> In other words, I've looked through the River codebase and from what I >> can see, the exception hierarchy already reflects a reasonable >> organization of exceptions, and to make the top-level of this hierarchy >> extend from a common exception would not make sense. The only common >> traits of TransactionException and LeaseExceptions is that they are both >> Exceptions. That commonality is accurately reflected by the fact they >> both subclass Exception. >> >> Cheers, >> >> Greg. >> >> On Thu, 2012-10-18 at 09:43, Simon IJskes - QCG wrote: >> > On 18-10-12 15:36, Gregg Wonderly wrote: >> > >> I see no problem in deriving all river exceptions that are >> > >> currently derived from Exception, now from RiverException extends >> > >> Exception. This would as far a i can see create no problems in >> > >> river as to compatibility. >> > >> > To make it more clear: To only change river exceptions that are directly >> > extending Exception. >> >>
