Re: Why do we capture the call stack when close() is called?

[Craig L Russell]

On Feb 8, 2007, at 3:32 PM, Patrick Linskey wrote:

It's there for debugging purposes. We could probably check for

to turn on TRACE logging to get the closure point.

TRACE-level logging; if not enabled, the exception would not be created and the assertion would include a localized string instructing the user

Craig

I like this. If you get an exception because your code accidentally called close(), it's really nice to be able to track it down instead of inserting a hundred printf's. But we should strive to avoid generating unnecessary stack traces because of the performance. +1 to check the log level and only capture and throw the call stack on close if the user is running TRACE.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.


by email and then delete it.

______________________________________________________________________ _ 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

-----Original Message-----
From: Kevin Sutter [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 08, 2007 3:27 PM
To: open-jpa-dev@incubator.apache.org
Subject: Why do we capture the call stack when close() is called?

Hi,
I've noticed that we capture the current call stack (via an
IllegalStateException creation) when close() is invoked on the
AbstractBrokerFactory and when free() is invoked on
BrokerImpl.  Then, if or
when assertOpen "fails" we include this exception (and call
stack) as the
cause of a new IllegalStateException.  I suppose this can be
useful for a
user that accidentally attempts to use a closed broker.  But,
capturing this
information in "production" mode is kind of expensive.  Do we
need this
processing at all?  If so, could we at least gate it's usage
on a TRACE or
DEBUG setting?  Or, any other ideas?

Thanks,
Kevin

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!

smime.p7s
Description: S/MIME cryptographic signature