On Sat, Oct 20, 2012 at 3:19 AM, Dan Creswell <[email protected]> wrote: > 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.
The main reason I did not just provide my wrapper class to the project was that it's not a very scalable solution and it duplicates functionality. My company used the registrar, Javaspaces, and Transactions, so my wrapper covered those fields and the ways in which they worked together. One could create one wrapper per service to better modularize for other usage cases, but all the wrapper does is provide a different way of providing the same functionality. Since we're speaking of design, having multiple ways of accomplishing the same ends with the same means seems dubious to me from a design perspective. We'd need a really good reason to split usage like that. If the community thinks backwards compatibility is a sufficient cause, fair enough, but I have my doubts. James > 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. >> > >>
