river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Grahn <grahn...@gmail.com>
Subject Re: River exception usage.
Date Tue, 23 Oct 2012 11:07:26 GMT
I had mentioned Spring in the original issue, as I was passingly
familiar that it had switched to using RuntimeExceptions almost
exclusively.   It is a potential solution.

Yet because networking is one of the more failure-prone areas of the
stack, Jini is more likely to be producing exceptions even in
well-tested code.   Moreover, also owing to the vagaries of
networking, Jini is also more likely than other code to be producing
_recoverable_ exceptions.   This does not seem the ideal usage case
for RuntimeExceptions, if you think there's a place for checked
exceptions at all.

I recommended a Jini or RiverException from my experience with other
libraries that had similar models.   Library-wide exceptions account
for my best experiences with checked exceptions from libraries.   Not
only does the practice reduce the number of potential catch/throws
statements one must write (both inside the project and in usage), but
it also serve to quickly pinpoint the problem region in the code: as a
developer, you're likely to have an awareness of just where Jini is
being used in your code, whereas an IOException might crawl out from a
greater number of call-sites.

The practice is something like a "marker interface", unfortunately
shoved into the proper hierarchy because Java constricts catch and
throw statements in that way.


On Fri, Oct 19, 2012 at 8: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.
>> >

View raw message