On Fri, Oct 5, 2012 at 9:19 PM, Gregg Wonderly <[email protected]> wrote: > Deriving from IOException would seem like a viable choice?
IOException is a reasonable in most of the cases discussed (network-originating), but has the potential to be misleading in some circumstances. For instance, a "CannotAbortException" or "LeaseDeniedException" is most likely not IO-generated. They are, however, definitely generated by the River library, and so deriving from RiverException would be appropriate. Even if the first assumption will always be "networking issue" in production code, it's not true for the entire universe of exceptions that River throws. > Gregg James > Sent from my Phone > > On Oct 5, 2012, at 7:17 AM, Simon IJskes - QCG <[email protected]> wrote: > >> On 05-10-12 13:29, James Grahn wrote: >> >>> 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. >> >> In concrete term, you would like to see RiverException as a catchable >> Exception for all river related problems. This would have 2 options, >> wrapping, or deriving. As there is no real single API, this would mean >> derive everything from RiverException. do you agree? >> >> Gr. Simon >> >> -- >> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl >> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
