db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: SQLExceptions and OutOfMemoryExceptions
Date Wed, 23 Nov 2005 15:48:57 GMT
Oyvind.Bakksjo@Sun.COM wrote:

> Daniel John Debrunner wrote:
>> Oyvind.Bakksjo@Sun.COM wrote:

>>> You would at least need to have one per thread.

>> Why? If I have a singleton as a static and never modify it, I can safely
>> throw it in multiple threads. It will have the fixed meangingless stack
>> trace, but this to handle a special case.
> The stack trace isn't created when the Exception object is constructed,
> it's created when it's thrown. If you throw the same exception object
> from multiple threads, they will interfer with each other in
> unpredictable ways.

That's not what I see in jdk 1.4.2, from IBM & Sun and jdk 1.5. Here's a
simple program that creates an exception in the method b() but throws it
in a(). I always see b() in the stack trace.

java.lang.Exception: from b
        at te.b(te.java:20)
        at te.a(te.java:15)
        at te.main(te.java:6)

I've always seen exceptions have the stack trace of where they were
created. That's also what the jdk 142 javadocs say for Throwable:

'A throwable contains a snapshot of the execution stack of its thread at
the time it was created'

public class te
  public static void main(String[] args)
      try {
      } catch (Exception e)

  public static void a() throws Exception
      throw b();

  public static Exception b()
      return new Exception("from b");


View raw message