db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: svn commit: r384605 - in /db/derby/code/trunk/java: engine/org/apache/derby/iapi/services/memory/ engine/org/apache/derby/impl/jdbc/ engine/org/apache/derby/jdbc/ testing/org/apache/derbyTesting/functionTests/tests/memory/
Date Thu, 09 Mar 2006 22:13:05 GMT
David W. Van Couvering wrote:
> This is great, Dan, it's great to get some extra robustness into the
> system.
> 
> I understand why you made the exception a static. As it stands in your
> code the original stack trace is lost, so how will I know who is
> throwing the static NO_MEM exception? 

I'm not losing any stack trace, well at least not in Jdk 1.5 and
earlier. The OutOfMemoryError does not contain a stack trace, and even
in jdk 1.6 is not guaranteed to contain one.

> As someone trying to debug the
> situation, for example, I wouldn't know if the NO_MEM exception was
> thrown in EmbedConnection or in one of two places in InternalDriver.
> 
> Wouldn't it make more sense to create a separate static instance for
> each situation?  I understand that this could be a bit expensive in
> terms of footprint, but I'm worried about debugging, determining what
> particular code-path caused the out-of-memory situation.

Possibly, though caring where this exception came from seems to be a
derby-developer concern and not an end-user one. One could obtain the
information using a debugger.

Though having two static variables would not give correct stack traces,
maybe not even different ones if line numbers are not compiled in.
Depends of course of where they are created, in different classes would
be a clue.

Dan.


Mime
View raw message