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. > >
