Have we got some examples in the real-world that suggest: (1) There's value in doing this. (2) It makes user code better. (3) The effects on current user-code are either minimal or acceptable given the benefits - see (1) and (2).
FWIW, I'm not sure I like this idea when it comes to lease usage. I like the explicit exceptions there, and I expect them, and I want to code for them because my own approach to distributed systems assumes failure and intelligent state reconstruction etc. I certainly wouldn't want or need the "convenience" of an exception I always have to invoke .getCause on followed by more processing. In some ways, this is like IOException which has a similar construct and I for one find it unappealing. Nevertheless, if there's merit why not equally if it breaks existing code we need a good reason for doing it, especially if it will break everyone's code because it's common. Two cents, Dan. On 3 October 2012 11:27, 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<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 >
