Re: throw oddities in pdd23
Stephen Weeks wrote: Commit 31294 implements this behavior. Can I get confirmation that it's correct? Just looked over the diff. Perfect. Thanks! Allison
Re: throw oddities in pdd23
Not long ago, Stephen Weeks proclaimed... Not long ago, Allison Randal proclaimed... Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with IEXCEPTION as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. This has been reverted. I'll fix it and commit again sometime soon. Commit 31294 implements this behavior. Can I get confirmation that it's correct?
Re: throw oddities in pdd23
Not long ago, Stephen Weeks proclaimed... Not long ago, Patrick R. Michaud proclaimed... Personally I like the idea that any PMC can be thrown as an exception, which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Pm This proposal has been implemented in the exceptionmagic branch. Looks like all tests are passing there without problem, although I'm not certain about a couple of the languages. Can I get some confirmation from someone else on the desirability of this proposal? This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree.
Re: throw oddities in pdd23
Stephen Weeks wrote: This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree. Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with IEXCEPTION as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. Thanks! Allison
Re: throw oddities in pdd23
Not long ago, Allison Randal proclaimed... Stephen Weeks wrote: This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree. Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with IEXCEPTION as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. This has been reverted. I'll fix it and commit again sometime soon.
Re: throw oddities in pdd23
Patrick R. Michaud wrote: PDD23:67 has: : =item Bthrow IEXCEPTION : : Throw an exception consisting of the given IEXCEPTION PMC. Active exception : handlers (if any) will be invoked with IEXCEPTION as the only parameter. : : : =item Bthrow IEXCEPTION [ , ICONTINUATION ] : : Throw an exception consisting of the given IEXCEPTION PMC after taking : a continuation at the next opcode. When a ICONTINUATION is passed in, : it will use that instead. Active exception handlers (if any) will be : invoked with IEXCEPTION and the given continuation as parameters. This looks weird in a couple of respects. The second Cthrow opcode shows ICONTINUATION as an optional parameter, which would seem to be in conflict with the first form (i.e., they end up being identical if ICONTINUATION is omitted). Next, reading the above makes it look as though exception handlers can sometimes be invoked with a single parameter (the exception) and sometimes with two parameters (the exception and a continuation). Perhaps it would be better to have a consistent calling interface? (I do suppose we could say that the second parameter is always optional.) I suspect much of the confusion comes from when Cthrowcc was (apparently) eliminated in favor of a single Cthrow opcode, but pdd23 wasn't made internally consistent. Yes, Cthrow and Cthrowcc were collapsed into one opcode, and left some editing junk behind. I just changed it to one entry for Cthrow. Also, note that the single-argument Cthrow opcode is currently doing more than simply cause exception handlers to be invoked -- it's also takes a resume continuation and stores it in the IEXCEPTION PMC itself (src/ops/core.ops:817). This would seem to be in conflict with the next sentence at pdd23:80 : : Any type of PMC can be thrown as an exception. Clearly we cannot use the single-argument Cthrow on a PMC that doesn't have a resume attribute for us to store the resume continuation. Personally I like the idea that any PMC can be thrown as an exception, which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Alternatively, we could say that Cthrow only places a resume continuation into PMCs that does exception, but somehow I find this less desirable than the above approach. Okay, PDD cleaned up. The code to directly support throwing any arbitrary type would require significant circumlocution (read: inefficient, difficult to maintain), so it's not desirable. It's not just a matter of removing the return continuation from the exception object, we'd have to remove all metadata from the exception object (stacktrace, payload, handler iterator, type and severity information), and either pass all that information as arguments throughout the system (expensive and error-prone) or store it as global state information (error-prone, and bad for a clean implementation of concurrency). But, an individual HLL can store any arbitrary PMC value as the payload of an exception object, and act as if it had thrown an arbitrary PMC as an exception. Allison
Re: throw oddities in pdd23
On Tue, Sep 16, 2008 at 10:14:24PM +0200, Allison Randal wrote: Okay, PDD cleaned up. The code to directly support throwing any arbitrary type would require significant circumlocution (read: inefficient, difficult to maintain), so it's not desirable. [...] But, an individual HLL can store any arbitrary PMC value as the payload of an exception object, and act as if it had thrown an arbitrary PMC as an exception. Works for me, thanks. Now I'm just eagerly awaiting comments on Stephen Weeks' proposals. :-) Pm
Re: throw oddities in pdd23
Not long ago, Patrick R. Michaud proclaimed... Personally I like the idea that any PMC can be thrown as an exception, which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Pm This proposal has been implemented in the exceptionmagic branch. Looks like all tests are passing there without problem, although I'm not certain about a couple of the languages. Can I get some confirmation from someone else on the desirability of this proposal?
