search for: program_error

...I should stop thinking C++ here.... it's difficult, but > I'll try... ;) OK :) Essentially what happens is as follows: when running destructors when exiting a scope (which may be a nested scope), if a destructor throws an exception then any remaining destructors are first run, then the Program_Error exception is thrown at the point of the scope exit. This may be caught by an enclosing handler. For example, in pseudo C++ code: { ... do some stuff ... { ... declare a variable A with a destructor that does not throw ... declare a variable B with a destructor that throws...

On 25 November 2010 11:03, Duncan Sands <baldrick at free.fr> wrote: > I don't understand what you are saying.  Cleanups (e.g. destructors) Hi Duncan, Cleanup landing pads normally call destructors, but they're not a destructor themselves. I'm simply saying that compiler generated blocks (such as cleanups) should never depend on user variables. But I get what you're

...hrow and exception inside a destructor and it does not lead >> to program termination. > > Interesting. I assume that the personality still sees these as just cleanups, > so this must be implemented by running the destructor in a handler which > aborts both unwinds and throws the Program_Error? Right. The dwarf exception library doesn't mind if you throw a new exception inside a cleanup, it just unwinds it. ["Cleanups don't throw" is a C++ specific concept that is built on top of the basic unwinder facilities; gcc does it by wrapping cleanup code in a no-throw filter...

...pent too much time thinking about inlining EH information yet. > OK :)  Essentially what happens is as follows: when running destructors > when exiting a scope (which may be a nested scope), if a destructor throws > an exception then any remaining destructors are first run, then the > Program_Error exception is thrown at the point of the scope exit.  This > may be caught by an enclosing handler. That's a neat model. What happens if two (or more) exceptions are thrown while you're cleaning up another? For instance, if A's destructor also throws an exception? A's exception...

Hi Renato, >> OK :) Essentially what happens is as follows: when running destructors >> when exiting a scope (which may be a nested scope), if a destructor throws >> an exception then any remaining destructors are first run, then the >> Program_Error exception is thrown at the point of the scope exit. This >> may be caught by an enclosing handler. > > That's a neat model. > > What happens if two (or more) exceptions are thrown while you're > cleaning up another? For instance, if A's destructor also throws an &g...

...> In Ada you can throw and exception inside a destructor and it does not lead > to program termination. Interesting. I assume that the personality still sees these as just cleanups, so this must be implemented by running the destructor in a handler which aborts both unwinds and throws the Program_Error? John.

...3:31, Duncan Sands <baldrick at free.fr> wrote: > In short, all destructors are run, and if any > throw > exceptions then that fact is noted somewhere (and the exception is not > allowed > to propagate) and once all destructors have had a chance to run then one > instance of Program_Error is thrown at the point of scope exit. I see, like keeping the exceptions in a queue as they happen and deal with each one in order, until the queue is empty. It's harder to print stack-traces to the user, but this discussion is becoming off-topic. ;) Anyway, thanks for the explanation! chee...

...side a destructor and it does not lead >>> to program termination. >> >> Interesting. I assume that the personality still sees these as just cleanups, >> so this must be implemented by running the destructor in a handler which >> aborts both unwinds and throws the Program_Error? > > Right. The dwarf exception library doesn't mind if you throw a new exception > inside a cleanup, it just unwinds it. ["Cleanups don't throw" is a C++ specific > concept that is built on top of the basic unwinder facilities; gcc does it by > wrapping cleanup...

...ldrick at free.fr> wrote: >> In short, all destructors are run, and if any >> throw >> exceptions then that fact is noted somewhere (and the exception is not >> allowed >> to propagate) and once all destructors have had a chance to run then one >> instance of Program_Error is thrown at the point of scope exit. > > I see, like keeping the exceptions in a queue as they happen and deal > with each one in order, until the queue is empty. not really, there is no queue and no need to keep track of the exceptions destructors are throwing [*]. The following pseudo...

Hi Renato, > On 25 November 2010 07:51, Duncan Sands<baldrick at free.fr> wrote: >> If you got to XYZ because an instruction threw an exception before %x was >> defined, then in XYZ you are using %x which was never defined. In effect >> the definition of %x in bb does not dominate the use in XYZ. I think the >> solution is to say that in XYZ you are not allowed

On 25 November 2010 07:51, Duncan Sands <baldrick at free.fr> wrote: > If you got to XYZ because an instruction threw an exception before %x was > defined, then in XYZ you are using %x which was never defined.  In effect > the definition of %x in bb does not dominate the use in XYZ.  I think the > solution is to say that in XYZ you are not allowed to use any values defined >