I'm not answering your question on your terms because that is shaped by
your belief as to what we're talking about... :)
The point is I don't need that exception. There are two general ways of
handling these things:
There's the "I don't care" strategy:
catch (Throwable aT) {
// Bail out big-time, give up, go home
}
A variation on that theme is to have everything be RuntimeException so you
don't even do the catches.
There's the "I care" strategy where good form is to catch as close to the
explicit exception as you can. In such cases I would expect separate
clauses for e.g. LeaseDeniedException and TransactionException and I don't
need to catch a higher-level base exception that I must then test with
instanceof and potentially downcast again. Such action is generally bad
style. There are um, exceptions, to the general case but they are rare
enough to not warrant explicit support.
So, for me, this additional exception doesn't fit usefully with either
strategy above. It'd be closer to "if it's a River-related exception" bale
big time otherwise keep running. That, to me at least, is not sensible. If
River is bailing, I'm gonna bail. And I'm probably gonna bail on anything
else "scary" from anywhere else as well.
People also seem to forget that context is king. I know what method I'm
invoking, I know therefore just which bit of code failed and I can catch
that failure in that context regardless of the name of the exception. Put
another way, the name of the exception should be related to the type of
issue not some convenient tidy-up, it's a classification of types of error
not the package that sourced the error. The code I'm invoking is River and
I know it so I don't need a special exception.
In conclusion and being blunt, this feels like an ugly cosmetic (irony)
change that gives no value but clutters up the classname space some more.
So it doesn't make my life harder but it's a pig with lipstick on and
there's no way I'm making out with that hog.
On 23 October 2012 09:06, Simon IJskes - QCG <[email protected]> wrote:
> On 20-10-12 09:19, Dan Creswell wrote:
>
>> Or maybe we provide a wrapper in the distribution?
>>
>> I'm with you, my recovery strategies are easier to code with the hierarchy
>> as it is.
>>
>>
> But you don't loose anything by accepting a JiniException as starting
> point for the different exception families.
>
> What i see here, is a group of people, rejecting a modification that would
> make life easier for some, without stating how it would make life harder
> for them.
>
> What does accepting this change make life harder for you?
>
> Please specify. With code examples.
>
