Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of dan.creswell@gmail.com
 designates 209.85.212.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A9CEB46D-A59D-4DC0-98FC-B4C6709136C5@wonderly.org>
References: <506C0F1D.7070301@qcg.nl>
	<1349259525.2932.291.camel@cameron>
	<506C1310.5010109@qcg.nl>
	<314C3A25-A518-49DE-A21E-651B40104142@cox.net>
	<506CA1E0.4050108@qcg.nl>
	<CAB4Zv9wS_1WU4OwxthKEgHnpXyJb8sGJY8F0Ly7gv6M8MXQmxg@mail.gmail.com>
	<506ECFE9.9070005@qcg.nl>
	<17965B3D-7778-4727-9635-1B9E198A1466@wonderly.org>
	<CAB4Zv9z=1sTCM_0ckBZsedv7mLGK6tPNeygiJxTenYNSHuuNNQ@mail.gmail.com>
	<507FC971.4080107@qcg.nl>
	<D360475D-09A6-49F5-A6D6-4843B0B79731@gmail.com>
	<50800794.8030603@qcg.nl>
	<1350573637.8209.34.camel@cameron>
	<CAB4Zv9wR2EPvTvvXwOvQm4MTdg59KuvJYCDn49jXeto5UNA2qw@mail.gmail.com>
	<1350648668.8209.89.camel@cameron>
	<A9CEB46D-A59D-4DC0-98FC-B4C6709136C5@wonderly.org>
Date: Sat, 20 Oct 2012 08:19:14 +0100
Message-ID: 
 <CAMPUXz-DWhpwuy3zdV8tYaNMeO+cVNkb6xSSOCqAfnhc8Ks1Cg@mail.gmail.com>
Subject: Re: River exception usage.
From: Dan Creswell <dan.creswell@gmail.com>
To: dev@river.apache.org
Content-Type: multipart/alternative; boundary=e89a8f503b7209481f04cc78704b

--e89a8f503b7209481f04cc78704b
Content-Type: text/plain; charset=ISO-8859-1

Or maybe we provide a wrapper in the distribution?

I'm with you, my recovery strategies are easier to code with the hierarchy
as it is.

On 20 October 2012 04:52, Gregg Wonderly <gregg@wonderly.org> wrote:

> Each time I use these facilities, there is enough variation in what I want
> to do for recovery, that I find it appealing that it is separated so that I
> can handle the exceptions individually.
>
> If you are fonding a common behavior, then a wrapper class or factory like
> static method might be what you need.
>
> Maybe we need to illustrate things with better docs?
>
> Gregg
>
>
> Sent from my iPhone
>
> On Oct 19, 2012, at 7:11 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:
>
> >
> > 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
> > objects?
> >
> > 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
> > http://www.mindview.net/Etc/Discussions/CheckedExceptions.
> >
> > 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?
> >
> > Cheers,
> >
> > Greg.
> >
> > 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.
> >
>

--e89a8f503b7209481f04cc78704b--