Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Tue, 22 May 2007 23:22:59 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-2472) Use Throwable.initCause() to
 improve error reporting
In-reply-to: <4651AD84.8030003@amberpoint.com>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <x7tzu4h7t8.fsf@Sun.COM>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <32471157.1179678076468.JavaMail.jira@brutus>
 <4650CFC4.7020005@amberpoint.com> <wjo81wha7c4g.fsf@sun.com>
 <4651AD84.8030003@amberpoint.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1.50 (usg-unix-v)

Bryan Pendleton <bpendleton@amberpoint.com> writes:

> Thanks for the very clear explanation, Knut Anders!
>
>> 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.
>
> +1 to all of these conclusions. The first exception is the most
> important, and attempting to amalgamate multiple exception chains
> into a single chain can mislead the user. Re-throwing the last exception
> seems like an inferior choice to re-throwing the first.

If it only were that simple... I made the change in
GenericLanguageConnectionContext and BasicDependencyManager and ran
derbyall and suites.All. Both had two new failures. Here's one of the
diffs (they all were similar):

********* Diff file derbyall/derbylang/fk_nonSPS.diff
*** Start: fk_nonSPS jdk1.6.0_01 derbyall:derbylang 2007-05-22 17:44:47 ***
321,323d320
< ERROR X0Y25: Operation 'DROP CONSTRAINT' cannot be performed on object 'PK1' because CONSTRAINT 'FK' is dependent on that object.
< ERROR X0Y25: Operation 'DROP CONSTRAINT' cannot be performed on object 'PK1' because CONSTRAINT 'FK2' is dependent on that object.
< ERROR X0Y25: Operation 'DROP CONSTRAINT' cannot be performed on object 'PK1' because CONSTRAINT 'FK3' is dependent on that object.
326,328d322
< ERROR X0Y25: Operation 'DROP CONSTRAINT' cannot be performed on object 'PK1' because CONSTRAINT 'FK' is dependent on that object.
< ERROR X0Y25: Operation 'DROP CONSTRAINT' cannot be performed on object 'PK1' because CONSTRAINT 'FK2' is dependent on that object.
< ERROR X0Y25: Operation 'DROP CONSTRAINT' cannot be performed on object 'PK1' because CONSTRAINT 'FK3' is dependent on that object.
Test Failed.
*** End:   fk_nonSPS jdk1.6.0_01 derbyall:derbylang 2007-05-22 17:45:09 ***

Before, the exception chain would show all the objects that were
dependent on the object being dropped, whereas with the change, only one
of the dependent objects is shown. I still think we don't lose very
important information, but I also see the value of getting all the
dependent objects at once. Any opinions on this?

-- 
Knut Anders