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 of code. I'm not sure that was really an issue here... but be careful with this sort of re-factoring (obviously there should hae been a comment about why this was there)... - Rob On 18/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
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 threads throwing the same exception instance simultaneously will work happily. Anyway, I've refactored out the *ugly* code, so I don't have to puzzle about these things. Rupert On 18/05/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > 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... 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 having enumerated error codes returned. > > > > > > It's *ugly* code, I'll grant you that :-) > > > > > > > > > -- Rob > > > > > > On 18/05/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > > 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. > I > > > not > > > > even sure that throw is thread safe in that respect? This could also > > > cause > > > > memory leaks, because objects refed by the static stack dump won't > be > > > > garbage collected. > > > > > > > > Rupert > > > > > > > > > >
