Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sat, 26 Aug 2006 12:46:21 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: [JUnit] Should assertSQLState throw SQLException?
In-reply-to: <44EE3C27.4010507@apache.org>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <8664gfwz9e.fsf@ugle.hatlen.net>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <86veoljkzu.fsf@ugle.hatlen.net> <44EB13C7.2070206@sun.com>
 <44EB27CE.2080203@Sun.com> <44EE3C27.4010507@apache.org>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix)

Daniel John Debrunner <djd@apache.org> writes:

> Kristian Waagan wrote:
>
>
>> Any suggestions on how we can achieve what Knut Anders is proposing?
>> I think it is a good proposal to preserve the stack trace, the error
>> message and the SQL state.
>
> I think we want to do something like this (which requires JDK 1.4 or
> higher), I'm looking at implementing this and maybe just lose the error
> in jdk1.3.
>
>
>         } catch (AssertionFailedError e) {
>
>             // Save the SQLException
>             e.initCause(exception);
>
>             throw e;
>         }
>
> around the asserts in assertSQLState() (except for assertion that
> exception is not null)
>
> This will save the stack trace.

Sounds good to me. I don't think it's a big issue that we lose the
error in jdk1.3.

> This could be followed on by code in BaseTestCase.runBase to always
> print the exception, or to save the exception's stack trace in the newly
> added "failed" folder (see BaseTestCase.getFailedFolder()).
>
> I don't think individual tests should be trying to print stack traces,
> if we can centralize it then we will end up with consistent results.
> E.g. well formatted information about SQLExceptions including the
> chaining. Having each test print exceptions will mean endless variety as
> to how they are printed and most missing the chain of exceptions. That's
> what happens today with the existing tests.

I agree. Thank you for all your hard work on the JUnit framework!

-- 
Knut Anders