This is an interesting thread and there are some good arguments both ways for it. I have my own opinion on the matter, but I can't add any more to the technical arguments than have already been made.
Ultimately though, making the change would require a modification to the public API and probably break backwards compatibility. If that's so, then whether we all agree with it or not, the change will require a vote and so I suggest that a vote is started. Cheers, Tom On Tue, Oct 23, 2012 at 12:07 PM, James Grahn <[email protected]> wrote: > Greg, > 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. > > James > > On Fri, Oct 19, 2012 at 8: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. > >> > > > >
