I generated this Jira issue because of my practical experiences working on a project that conducted most/all of its networking over Javaspaces.
Because the majority of our interactions over network were conducted through Javaspaces/Jini, invariably all exceptions wound up meaning the same thing. Any and all exceptions originating from Jini after our development phases were assumed to be network breakages (and over 90% were network breakages). The only valid responses, then, from any Jini-originated exception were: fail, retry. For years, the company bubbled every exception thrown by Jini in order to reach code that could make the fail/retry decision. As a result, many methods threw a laundry list of exceptions all of which signaled the need for a single behavior. Because of this, I was tasked with creating a wrapper to insulate the rest of our code from our Jini usage. Essentially, the wrapper did the following: 1) Contained ugly where-is-my-space and where-is-my-transaction-manager code 2) #RIVER-380 - increased consistency in naming of space methods following conventions from Collections 3) #RIVER-381 - standardized the return type from multi-return space methods 4) #RIVER-382 - (current subject) standardized Jini exceptions 5) #RIVER-384 - utilize generics so that the method signatures of Javaspace match the contractual obligations in the comments. There's no particular reason why the River project couldn't make the entire wrapper unnecessary as it seeks to make improvements. The current subject of discussion, #RIVER-382, would generalize reasonably well to other River users, I feel. Jini encapsulates network usage, which necessarily is more sensitive to the runtime environment than a generic piece of code. Thus, it's more liable to generate exceptions than most libraries. I suspect that many users don't particularly care what exactly went wrong in the network during runtime, because the primary responses are retry/fail. Very few people require anything else, and those that do can use getCause. I think the analogy holds with the JAXB example, which unified its thrown exceptions to offer "something wrong relating to the XML". RiverException would similarly be "something wrong with the network" except during initial development when you'd care more about the full stack trace. --- #RIVER-380, #RIVER-381, and #RIVER-382 are all breaking changes to the API, and so would have to wait for a major version, probably. But I do feel they are all practical improvements. james On Wed, Oct 3, 2012 at 4:36 PM, Simon IJskes - QCG <[email protected]> wrote: > On 03-10-12 21:08, Gregg Wonderly wrote: >> >> Any remote, catchable exceptions should be "RemoteException" >> subclasses, and where applicable, they should be subclasses with >> viable names. Anything that comes from the APIs of River, just needs >> to be specifically about the type of issue. I, personally, only wrap >> things in "RuntimeException" when I need to change the visibility, >> from an API perspective, of where something is caught and handled, vs >> having to expose some logic to another package which involves an >> exception it doesn't care about. >> >> Maybe James could provide some more specifics? Or, Simon, maybe you >> can shed some light on how you are thinking about this issue? > > > I was in the process of composing an email, but soon it started to 'ramble'? > We can see, there are multiple families of Exceptions grouped per > sub-system. A family centered on a shared parent so to speak. The original > ticket talks about 'spaces' and exceptions bubling up. River doesn't have a > clear cut API boundary, you can use the subsystems however you want, and the > 'getCause' unwrapping is also not so beautyfull. I tought for a moment to > derive everything from RiverException, but then we have all those rmi > derived exceptions and classes. So like everything it is not so simple. > > I hope James Grahn can speak of his experiences, and otherwise if we cannot > prove a real benefit we should at least close the ticket as wontfix, until a > better business case can be developed. > > Gr. Simon
