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: open-jpa-dev@incubator.apache.org
Subject: Re: RollbackException.toString()
What
Our internal testing framework, in this case, is vanilla JUnit. Seems
like that might be a use case that we should care about, no?
IMO, you don't subject all your users to nonstandard behavior (in
this case, adding a stack to an exception's toString) to satisfy one
braindead testing harness
Hi,
It would seem that RollbackException's toString() doesn't print out
nested exceptions by default. Is this intended? If so, is it desired
behavior?
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
___
Notice: This email
As with all the the org.apache.openjpa.persistence.*Exception
classes, it appears to defer to
org.apache.openjpa.util.Exceptions.toString(ExceptionInfo), whose
behavior is presumably expected. Since JDK 1.4/1.5's
Throwable.toString() doesn't print out nested exception messages, I
don't
The situation I'm looking at right now, for one: I'm seeing an
optimistic lock exception, and the OpenJPA exception translation is
obscuring the full stack, so I just get the stack from the point of
translation, rather than from the point of origin.
Then the solution is to fix the exception
The situation I'm looking at right now, for one: I'm seeing an
optimistic lock exception, and the OpenJPA exception translation is
obscuring the full stack, so I just get the stack from the point of
translation, rather than from the point of origin.
Then the solution is to fix the
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
