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
