river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: River exception usage.
Date Thu, 18 Oct 2012 18:05:27 GMT
+1

Agreed

On Thu, Oct 18, 2012 at 2:02 PM, Dan Creswell <dan.creswell@gmail.com> 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 <trasukg@stratuscom.com> 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.
>>
>>

Mime
View raw message