db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-2472) Use Throwable.initCause() to improve error reporting
Date Mon, 21 May 2007 09:35:27 GMT
Bryan Pendleton <bpendleton@amberpoint.com> writes:

>> 	} catch (StandardException e) {
>> 		e.initCause(topLevelStandardException);
>> 		topLevelStandardException = e;
>> 	}
>
> I don't quite understand the pattern above, probably because
> I don't understand the purpose of the "topLevelStandardException"
> variable. It seems like a more typical pattern for chaining
> exceptions would be something like:
>
>  	} catch (StandardException e) {
>                 StandardException ourException =
>                    StandardException.newException(SQLState.whatever...);
>                 ourException.initCause(e);
>                 throw ourException;
>  	}

I agree that this is a more typical pattern, and what one normally
wants. The reason why it's not done like that in the methods I referred
to, is that the operation continues on an exception and delays the
re-throwing until the operation has completed. Therefore, we might get
more exceptions after catching the first but before re-throwing it. The
pattern above tries to preserve all the exceptions that were seen during
the operation, and throw them as one long chain. With the more typical
pattern you suggested, the operation will be aborted on the first
exception, so we never see the other exceptions (and the operation
doesn't run until it's complete). Does that make more sense?

One might of course argue that we're only interested in the first
exception anyway (since the subsequent exceptions probably are identical
to or caused by the first exception). Then we could have something like
this instead:

    } catch (StandardException e) {
        if (topLevelStandardException == null) {
            topLevelStandardException = e;
        } else {
            // do nothing, we already have one exception that we will
            // re-throw once the loop has ended
        }
    }

As I can't see that the subsequent exceptions will provide any
significant value, I'm tempted to go for this solution. The code will be
a lot simpler this way, and I think it would also be clearer what the
problem is if an exception is thrown. As it is today, the last exception
we caught is the one that is re-thrown. This exception may have a
message that is completely unrelated to the real error, which you only
see if you go to the end of the chain.

-- 
Knut Anders

Mime
View raw message