Not long ago, Patrick R. Michaud proclaimed... > In August [1] I posted some code to test the ability to > resume execution after a thrown exception. Here's a new > version of that code, updated for other recent changes > to Parrot's exceptions: > > .sub main :main > push_eh catcher > 'foo'() > pop_eh > say 'ok 4' > .return () > catcher: > .get_results ($P0) > $P1 = $P0['resume'] > $P1() > .end > > .sub 'foo' > say 'ok 1' > $P0 = new 'Exception' > throw $P0 > say 'ok 2' > $P0 = new 'Exception' > throw $P0 > say 'ok 3' > .end > > As before, I'm simply trying to test the ability to > resume after exceptions thrown by C<foo>. > > Currently Parrot disables exception handlers when they're > invoked, thus the above results in "No exception handler" > when the second exception is thrown. What do we need to > modify in Parrot so that the exception handler isn't > automatically disabled? > > (In response to my August message Allison noted that > we needed to update "legacy" exception handlers for the > new model -- so I've begun the process of doing that update. > But now I need to know the appropriate patch or change to > make to Parrot so that it no longer disables handlers > upon invocation, so that I can complete the updates of > existing handlers.)
EHs are marked as "used" in src/scheduler.c:760 src/pmc/exceptionhandler.pmc:214-219 contain the logic for "If I am marked as used, decline to handle the exception." If you want to preserve the idea of a disabled exception handler still in the list of EHs in the context, you'll want to reorder the logic there so that it declines before it checks to see if a type or severity filter is in place. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
