river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon IJskes - QCG <si...@qcg.nl>
Subject Re: River exception usage.
Date Wed, 03 Oct 2012 20:36:48 GMT
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