river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: River exception usage.
Date Fri, 19 Oct 2012 12:11:08 GMT

Hi James:

Is it possible that what you're really looking for is unchecked
exceptions, a-la Spring's "unified exception hierarchy" for data access

Because what I hear you saying is "handling exceptions is a nuisance". 
And you're right, especially when, at the user-interface level, there's
typically not much you can do about an exception except tell the user to
try again later.

I have to confess that my personal thinking on checked vs unchecked
seems to vary over time.  Generally I find I'm tending towards unchecked
exceptions except in cases where I don't feel that I can adequately
unit-test.  Unfortunately that covers most of the network situations
that Jini/River is good for, so I guess that the exception handling is a
"cost of doing business".

 I've come across some good discussions on the issue at
http://www.artima.com/intv/handcuffsP.html and

Your concern is valid.  I don't know what the best solution is.  I'm
pretty sure that it isn't a single unifying exception based on the fact
that it's from the same jar file.

Suggestions, anyone?



On Thu, 2012-10-18 at 16:28, James Grahn wrote:
> My concern - the reason for which I raised the issue in the first
> place - was similarly a "code smell".   Individually considered, I
> agree that the current exception hierarchy is acceptable.   There's a
> sound reasoning behind each part of the hierarchy.   Yet my objection
> is not to the pieces, but the gestalt.
> Obtain a Javaspace, obtain a transaction manager, get a transaction,
> read from that space under transaction, write to that space under
> transaction, commit.   How many exceptions must be dealt with for this
> minimal workflow?   Multiply this by the number of times you use
> Javaspace, and you're either writing a hygiene layer to bring it under
> control or you're left with verbose, less readable code everywhere
> River touches.   That, too, is a code smell.
> I suspect that there may be an experiential difference between those
> building their own services on top of Jini/River, and those using
> what's already there.   Those who wish to add a layer on top of
> Jini/River very likely must care about every possible exception and
> handle them all individually.   A unified exception hierarchy would
> not exclude those building services, but would - in my opinion - ease
> the way for raw usage in applications.
> An "improved new user experience" is a topic that occasionally
> surfaces on this list and I believe removing hurdles to raw usage
> would qualify under that category as well.
> As for the other major concern: as mentioned before, yes, this is a
> change that breaks compatibility.   It would need to be reserved for a
> major version change or delayed until something else is going to break
> backwards compatibility anyway.   It would also require a broad
> consensus for the change (which does not appear to be emerging).
> I speak only from my own experience, but this change would have been
> welcomed at the company where I worked.
> james
> On Thu, Oct 18, 2012 at 11:20 AM, 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.
> >

View raw message