Many current users of River/Jini have "IOException" on remote interfaces, or still RemoteException, a subclass of IOException. In the end, I really do find IOException subclassing to be what seems right. If you change the hierarchy to derive directly from Exception, then I will have no choice but to completely rewrite lots of code in lots of places with lots of review time, to make sure I am still handling the scenarios that I programmed to, originally, still in a correct manner.
Can you elaborate more on your reasoning about "misleading in some circumstances"? When would a remote call not involve "I/O", marshaling/unmarshalling, or some other external interface, where there was an exchange between separate entities. Gregg On Oct 18, 2012, at 4:18 AM, Simon IJskes - QCG <[email protected]> wrote: > I see no problem in deriving all river exceptions that are currently derived > from Exception, now from RiverException extends Exception. This would as far > a i can see create no problems in river as to compatibility. > > On 12-10-12 16:57, James Grahn wrote: >> 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 >
