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.
