Would it be worthwhile to look at how JUnit handles cause() and change it to be a bit more detailed? There might already be some flag to cause it to behave differently. OOTH, JUnit was around long before cause() was introduced, so it might just need a patch to behave better.

Anyone care to poke into the JUnit sources to get the answer?

Craig

On Oct 31, 2006, at 1:39 AM, Patrick Linskey wrote:

Our internal testing framework, in this case, is vanilla JUnit. Seems
like that might be a use case that we should care about, no?

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

______________________________________________________________________ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this
by email and then delete it.

-----Original Message-----
From: Abe White
Sent: Monday, October 30, 2006 4:06 PM
To: [email protected]
Subject: Re: RollbackException.toString()

What is this 'inner exception' that you speak of? The underlying
exception is set to the cause, but the cause is not being printed.

IOW, I get all the information I need when I do an
e.printStackTrace()

OK, that's how it should be then.  I don't want to deviate from
Java's standard Exception.toString() behavior for all users just
because our internal testing harness happens to be braindead about
reporting errors.


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to