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? Gregg On Oct 3, 2012, at 5:27 AM, Simon IJskes - QCG <[email protected]> wrote: > If you want just a global direction to point to. For instance when you are > reporting to users. Now you need a whole dispatch with different exceptions. > I can see value in it, and if you don't does it matter? > > On 03-10-12 12:18, Greg Trasuk wrote: >> >> Would that be appreciably different than the way they currently all >> extend java.lang.Exception? I mean, if you don't care about what caused >> the exception, why would you care about whether it came from River? >> >> Greg. >> >> On Wed, 2012-10-03 at 06:10, Simon IJskes - QCG wrote: >>> Re: https://issues.apache.org/jira/browse/RIVER-382 >>> >>> Any objections to implementing this? >>> >>> Gr. >>> >>> -- >>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl >>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 >> > > > -- > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
