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
