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 > > > > > >
