> > 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
Well Perl 6 thinks that those should be contained within (or generatable from) the exception object itself, not attached as properties. But I'm sure it could emulate those properties, or vice versa, so not a big deal. > 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. Exceptions are traditionally done using inheritance, which I think fits the bill quite nicely (unlike most other things inheritance is used for ;-). I'm not sure doing handling based on textual patterns is such a good idea.... But inheritance isn't quite versatile enough for Perl. I suppose in the tricky cases Perl could install a "universal base class" handler, and then do its magic from the handler code. Just, er, I'm not for exception globs. > [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 Luke
