On 9 August 2013 11:48, Jonathan S. Shapiro <[email protected]> wrote: > On Thu, Aug 8, 2013 at 5:19 PM, William ML Leslie > <[email protected]> wrote: >> >> On 09/08/2013 7:57 AM, "David Jeske" <[email protected]> wrote: >> > If we wish to preserve that stack for future handlers, no handler can be >> > allowed to set the stack pointer (unroll) unless it is ending the exception >> > propagation. > > That's to strong. First, the backtrace printing mechanism isn't done in a > handler. It's done deep in the runtime. Second, it's perfectly fine for > unwind code to change the stack pointer. All we need to do to support the > backtrace is to save the stack pointer that was current at the time of the > most recent exception on that thread.
That doesn't seem sufficient, because all of the stack above the frame of the handler can be overwritten by the handler. A pointer into space that is available for allocation is not useful. > If we're running code in a catch block or a finally block, we're no longer > interested in a stack trace from the original raise. If 'we' was the CLR or Java, then we would be, because we might attach the original exception (with its traceback) as the 'cause' field. Some languages allow you to re-raise the original exception, without replacing its traceback; a useful technique when you don't know statically which conditions you want to catch, or when you want to log all exceptions that cross some boundary. I would like to think that you're right at least when 'we' are bitc - those of us implementing language runtimes in the language can use our own mechanisms to describe traceback semantics - except that the presence of finally blocks shouldn't interfere with the ability of the runtime to describe the stack that actually raised the exception. Finally blocks should *not* prevent the thread-exit exception handler from creating a traceback! > You guys are way over-thinking this. Well, naive exceptions - longjmp style - are able to express David's criteria. If we don't care about being able to create and manipulate tracebacks for caught exceptions, we're fine. But I agree with the CLI architects that this is a nice thing to be able to do. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
