+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. > >
