river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Grahn <grahn...@gmail.com>
Subject Re: River exception usage.
Date Fri, 05 Oct 2012 11:29:20 GMT
I generated this Jira issue because of my practical experiences
working on a project that conducted most/all of its networking over

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.


On Wed, Oct 3, 2012 at 4:36 PM, Simon IJskes - QCG <simon@qcg.nl> 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

View raw message