RE: RollbackException.toString()
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: open-jpa-dev@incubator.apache.org 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.
Re: RollbackException.toString()
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 (in this case, JUnit with Surefire, apparently -- I haven't seen the problem myself, so I don't know the details). I mean, a testing harness that doesn't print the stack trace of errors? It's like holding back the entire class to go at the pace of the kid in the corner with the bicycle helmet on.
Re: RollbackException.toString()
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 see any reason why we should. Furthermore, in cases where there are many nested exceptions (e.g., when a rollback occurs due to many optimistic violations, which has a nested exception per failed instance). Are there any specific cases where you think the toString() would be nice to have? On Oct 30, 2006, at 7:21 AM, Patrick Linskey wrote: 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 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.
Re: RollbackException.toString()
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 translation, which is always supposed to preserve the original stack (either by transferring it or making it an inner exception).
RE: RollbackException.toString()
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 translation, which is always supposed to preserve the original stack (either by transferring it or making it an inner exception). 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(), but not in the surefire log.
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.
