Scott Oaks wrote:
>>> I was just going to bite my tongue, but I will argue that the finally
>>> clause is far, far better. Exception chaining is a frustrating thing;
>>> it makes root cause analysis very difficult. I definitely agree that
>>> in most cases it is a mistake...
>>
>> In my case I was never going to expose original exception to the caller.
>> The caller wants to know that the connection failed, not that there was
>> a programming error in the connection provider that caused it to throw
>> NullPointerException.
>
> YMMV of course, but I'd argue that the common case is that the caller
> does want to know that there was a programming error that caused a NPE;
> they want to to know why the connection failed.
Right, which is why I chain the exceptions. But I give them an exception
they expect and can do something about.
> First, the caller can
> figure out if they might have inadvertently passed a null value
> somewhere. And if not, the caller can then accurately file a bug report
> against the connection provider. I just don't see where putting the
> exception within some other exception provides any value.
It groups unexpected failures with expected failures and allows the
caller to handle them consistently.
But really, the exception chaining wasn't the point of the original
question. It was how to do the cleanup when there's *any* kind of failure,
no matter how that failure is reflected to the caller.