On Tue Aug 05 04:09:14 2008, tene wrote:
> pdd23:
>
> Exception handlers can resume execution immediately after the
> "throw" opcode by invoking the resume continuation which is stored
> in the exception object. That continuation must be invoked with no
> parameters; in other words, "throw" never
Not long ago, Patrick R. Michaud proclaimed...
> Here's a simple test for resumable exceptions that I'm trying
> to get to work. I'm probably coding/understanding something wrong,
> so any suggestions or pointers would be greatly appreciated.
>
> .sub main :
Patrick R. Michaud wrote:
What I'm trying to do is to test the ability to resume after
exceptions thrown by C. The C sub above sets up
a handler to catch exceptions, then calls C. The handler
simply resumes any exception that is caught. The C sub
prints 'ok 1', throws an exception, prints 'ok
Here's a simple test for resumable exceptions that I'm trying
to get to work. I'm probably coding/understanding something wrong,
so any suggestions or pointers would be greatly appreciated.
.sub main :main
push_eh catcher
'foo'()
1c4aa1f 100644
--- a/t/op/exceptions.t
+++ b/t/op/exceptions.t
@@ -6,7 +6,7 @@ use strict;
use warnings;
use lib qw( . lib ../lib ../../lib );
use Test::More;
-use Parrot::Test tests => 29;
+use Parrot::Test tests => 30;
=head1 NAME
@@ -608,6 +608,29 @@ Exception message: Class Foo already
,
> the stack is not unwound until some exception handler chooses to
> unwind it by "handling" the exception in question.
Yes, I did. I was grepping specifically for the bit on resumable
exceptions and the quoted bit is 80 lines up so I missed it completely.
Thanks for poin
alls the LEAVE block to release the lock at some later
: date, seems to be far from the best choice. Sure, we can warn
: programmers to make their resumable-exception handlers short, or to only
: throw non-resumable exceptions from blocks that are likely to be called
: in such circumstances. I suppose that
we can warn
programmers to make their resumable-exception handlers short, or to only
throw non-resumable exceptions from blocks that are likely to be called
in such circumstances. I suppose that would be an acceptable resolution,
but it has an aura of non--re-entrant signal handlers about it, so it
the terminate-only camp.
: I don't remember what the "killer" argument was. But I do remember bits
: and pieces: people with real-world experience on systems that have
: resumable exceptions in some form ended up never using them; it
: complicates the implementation; it is not
eople with real-world experience on systems that have
resumable exceptions in some form ended up never using them; it
complicates the implementation; it is not necessary since callbacks fill
that role already (e.g. new_handler instead of resuming from the
bad_alloc exception); and the semantic c
On Wed, Jun 14, 2006 at 08:59:02PM -0700, Chip Salzenberg wrote:
: Are Parrot exceptions now, in fact, resumable? If they are, is that
: important? Is anyone actually resuming execution after exception handlers
: are called? I think we _can_ keep resumability, but I'm not sure I want us
: to, an
Are Parrot exceptions now, in fact, resumable? If they are, is that
important? Is anyone actually resuming execution after exception handlers
are called? I think we _can_ keep resumability, but I'm not sure I want us
to, and I definitely don't want to bother if no one wants it.
--
Chip Salzenbe
12 matches
Mail list logo
