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

[Kevin Sutter <kw...@gmail.com>]

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

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

[robert burrell donkin <ro...@gmail.com>]

On 2/9/07, Craig L Russell <Cr...@sun.com> wrote:
>
> 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.

+1

- robert

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

[Craig L Russell <Cr...@Sun.COM>]

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:kwsutter@gmail.com]
>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

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

[Patrick Linskey <pl...@bea.com>]

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.

-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:kwsutter@gmail.com] 
> 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
>