On Feb 8, 2007, at 3:32 PM, Patrick Linskey wrote:
It's there for debugging purposes. We could probably check for
TRACE-level logging; if not enabled, the exception would not be
created
and the assertion would include a localized string instructing the
user
to turn on TRACE logging to get the closure point.
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.
Craig
-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: 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
