Stephen Weeks (via RT) wrote:
There are some issues that need to be resolved for resumable exceptions. The first issue I've run into is that Parrot_cx_find_handler_local marks the exception handler as used when it finds it and ignores already-used exception handlers.
This is an intentional feature for backward-compatibility, but not one we'll be keeping permanently.
[...]
Parrot_cx_find_handler_local uses an iterator for handlers for Exceptions, but just walks all the handlers ignoring used ones for everything else. It looks like maybe if everything stored their handlers in an iterator, as the comment suggest is possible, we could discard the used check?
The handlers are stored in an iterator so 'rethrow' knows to pick up the next handler. Making non-exception events and tasks store an iterator for their handlers wouldn't make any difference here, since the problem is specifically with exceptions getting the wrong handler.
Handlers aren't marked as used to allow a single exception to iterate through them, they're marked as used because the existing PIR code using exceptions has a nasty habit of falling into infinite loops when an exception is thrown in the middle of handling another exception.
A few experiments into this turn up segfaults and other odd behavior.
If you dig into them, you'll find that they're caused by exception handlers catching exceptions that they didn't expect, and just assuming it's the anticipated exception. What's needed is a sweeping revision to existing uses of exceptions to make them check the type of the exception they're passed and rethrow anything they can't handle.
Maybe we need to have a 'cleanup' function for exception handlers to call instead?
We have 'pop_eh' to manually remove exception handlers. Are you thinking of some other cleanup behavior? If so, what?
Allison
