Ok, Rob has convinced me he is right. The stack trace gets filled in on the
constructor, 'fillInStackTrace' is available for bringing it up to date if
needed. Makes sense, or else catch and re-throw would lose the stack trace
below the catch point.
On 18/05/07, Rupert Smith <[EMAIL PROTECTED]> wr
Is that really the case? Then the stack trace wouldn't take you back to the
throw point, but to the creation point? I've found opinions that state both
cases. Going to have to look that one up I think...
On 18/05/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
The stack trace is generated on Exce
The stack trace is generated on Exception creation, not on throwing...
so it is completely safe. The stack trace in that exception would be
the stack at class instantiation.
This sort of trick is normally used where the exception is thrown
quite frequently in a semi- performance critical piece o
Well, I'm actually not sure that the stack trace really does hold references
to the objects in it, or just a listing of the class names and line numbers.
Also do exceptions hold the stack traces on a per-thread basis, as if they
are thread locals? Again I'm not sure, but if they do then multiple t
Absolutely !
On 18/05/07, John O'Hara <[EMAIL PROTECTED]> wrote:
Perhaps worth some comments to that effect, given it is a bit wierd.
On 18/05/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
>
> No - its a single instance of the Exception. So there's no leak...
> and the stack is not interesting
Perhaps worth some comments to that effect, given it is a bit wierd.
On 18/05/07, Robert Godfrey <[EMAIL PROTECTED]> wrote:
No - its a single instance of the Exception. So there's no leak...
and the stack is not interesting... and there's no thread safety
issue
The exception is used to flag
No - its a single instance of the Exception. So there's no leak...
and the stack is not interesting... and there's no thread safety
issue
The exception is used to flag a particular type of exception which
leads to an AMQP error
There's no need to have the stack trace retained.
It's just like h
Just found this shocker:
private static final ExistingSubscriptionPreventsExclusive
EXISTING_SUBSCRIPTION =
new ExistingSubscriptionPreventsExclusive();
Looks like a really bad idea as doesn't seem thread safe, as mutliple
threads raising these exceptions will overwrite each others stacks
