Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exception handlers really strike me as anonymous lexically scoped
> subroutines that get called with just one parameter--the exception
> object. As far as the engine should be concerned, when an exception
> is taken we just take a continuation with the address being the start
> of the code that handles the exception.

Reading through pdd06 the following is not really speced (IMHO):

       Exception handlers are dynamically scoped, and any
       exception handler set in a scope will be removed when that
       scope is exited.

How do we remove exception handlers on scope exit. Is this done, when we
encounter a C<pop_pad> instruction? Or should the HL emit a C<clear_eh>
opcode?
As the exception handlers live on the control stack, there is not much
connection between a lexical pad being popped off and removing
exceptiion handlers in scope.

> I'm not yet sure whether it's worth having engine support for
> specific exception type checking

I think we would have:
- Exception handler = Continuation
- Exception object = a new class of some type[2]. When the system throughs
  an exception, it would attach 2 properties to the exception object:
    "class" - exception class, e.g. math.div_by_zero[3] or so
    "text"  - textual representation

The system then could check:
- does the exception handler has a matching[1] "class" property and if yes
  call it, if no walk up the control stack.

[1] is wildmat(3) so its totally up to the usercode if the exception
    handler gets called. If the Continuation object (the exception
    handler) has a property of C<class="*"> it catches all, if its
    e.g. C<class="math.*" it catches all math exceptions.
    When user code wants to do it all, it could have a C<class=*>
    property and another e.g. "UserClass" property for its own type
    checking.

[2] e.g. a Hash where we compare hash data against the handlers
    properties.

[3] Classifying all kinds of exception would need a fair amount of work.
    We have:
    - system exception (e.g. SIGFPE): we need signal handlers
    - internal_exception(): a lot of them are probably panic()s
    - user code exception: up to the HL/programmer

Yet another question: Will we have semantics of repeating a failed
instruction or continuing e.g. after a SIGFPE at bytecode level / in
C-code?

Comments welcome,
leo

Reply via email to