Re: Implementing Exception Handling in a VM

Barry Kelly wrote:

Doing it manually in the interpreter loop: the way you do it depends on
what you want, but it basically involves walking up the call stack. If
you want a debugger to pick up on unhandled exceptions, you've should
probably do two walks: once to look for handlers until you find one, and
then walk the stack again and free up all the stack frames including all
locals (important if you've got C++ destructor-like semantics on any of
your types) and execute 'finally' blocks (unwinding). Once your done
with that and you've gotten the handler from the first walk, you simply
set up your machine to execute inside it. If you don't need the debugger
support, you can just do one walk that does both.

Why does a debugger require to walk the stack twice?
I cannot find such a requirement in your explanation.

IMO a pre-search for an exception handler is required only, when the
language allows to resume operation in an different place, outside the
exception handler that caught the exception. I understood this behaviour
as something like "repair and resume", perhaps related to Basic
Resume[same/next/linenumber]-style exception handling.

There remain more aspects to be specified, for a specific SEH model:
What does it mean that a debugger can "handle" exceptions?
Where can operation resume, after a exception has been handled?
Can handlers be implemented for specific exceptions?
(and possibly more)

Only if a double stack-walk is required, handlers for specific
exceptions require more considerations. Then the decision cannot be made
in user code, because the stack may not already have been unwound. This
is why in .NET a distinction is made between (compiler provided)
"filter" code, and (user provided) "handler" code.

This is why I ask for a more detailed discussion, whether multiple stack
walks are a requirement, and the role of debugging in this decision.

[...]
The two-walk approach described above is basically the way that both
..NET and Win32 SEH work, AFAIK, in order to get good debugger support.
If it unwound while searching for a handler, you wouldn't be able to
inspect the function context at the point where an unhandled exception
was thrown.

I cannot see how the operation of an debugger is related to a known
location of the exception handler code, determined by a first walk
through the stack?

DoDi

.

Relevant Pages

  • Re: Exception Handling...
    ... >>The try key word results in the current stack frame base, ... > private data on top of the Exception Registration... ... is the address of the exception handler. ... >>Immediately following this jump, there is inserted a jump to ...
    (comp.lang.pascal.delphi.misc)
  • Re: How to force the program to continue after unhandled exception detection
    ... Add this handler for form's Load event: ... Run the application without debugger: ... The debugger detects the unhandled exception and stops the program at ... When I set up a ThreadException handler correctly, by subscribing the handler before I call Application.Run, then once the debugger detects the exception and interrupts the program, I can simply continue execution and the program continues running just as it would have had the debugger not been present. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Implementing Exception Handling in a VM
    ... Why does a debugger require to walk the stack twice? ... Delphi) to only pop up the debugger if the exception isn't caught deeper ... MP> EXCEPTION_REGISTRATION structures until it finds a handler for the ...
    (comp.compilers)
  • Re: How to force the program to continue after unhandled exception detection
    ... Run the application without debugger: ... The debugger detects the unhandled exception and stops the program at ... ThreadException event correctly. ... When I set up a ThreadException handler correctly, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: ada compiler?
    ... high that the exception handler itself will overflow the stack (e.g. ... Storage_Error (without any further operations in the handler) would fail the ...
    (comp.lang.ada)