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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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. > > >
