# New Ticket Created by Paul Cochrane
# Please include the string: [perl #40714]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40714
The procedure eval_is() in languages/tcl/lib/test_more.tcl needs to be
able to
A thread on p5p recently brought up the idea of multi-language exceptions.
That is, instead of throwing exceptions with English C-strings embedded in
the source code, use a localization system.
If there'll soon be a push to clean up all of the uses of exceptions in the
source code (to make
Yes please!
On Oct 6, 2006, at 4:27 PM, chromatic wrote:
A thread on p5p recently brought up the idea of multi-language
exceptions.
That is, instead of throwing exceptions with English C-strings
embedded in
the source code, use a localization system.
If there'll soon be a push to clean up
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
my $i = 0;
class A { method inci() { die
Aaron Sherman wrote:
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
Corrected example follows (there were
On Wed, Oct 04, 2006 at 10:35:05AM -0400, Aaron Sherman wrote:
: Damian Conway wrote:
:
:@bar».foo if $baz;
:
: That brought to mind the question that I've had for some time: how are
: exceptions going to work on hyper-operators?
:
: Will they kill the hyperoperation in-progress? e.g. what
What is the behaviour of an *uncaught* exception, particularly with
respect to CHECK/END/LEAVE/LAST blocks, destructors, overloading of
the stringify operator on exception objects, the order in which these
things are executed, and the exit code of the process? (And anything
else that I haven't
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40218]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40218
So sayeth the docs for the get_*_hll global opcodes:
If the global doesn't
solution as a
[PDD] ticket for the extending, embedding, and external C API PDDs
(10-12, and possibly 2 and 23)? How we handle exceptions and
control-flow across C/Parrot boundaries is an important question, and I
want to make sure we address it.
Thanks,
Allison
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Sun, 30 Jul 2006 21:58:36 +0200
Am Sonntag, 30. Juli 2006 04:50 schrieb Bob Rogers:
The attached patch detects cases where a continuation tries to enter a
runloop different from the one that is executing, and prints a warning
to
From: chromatic [EMAIL PROTECTED]
Date: Sat, 29 Jul 2006 21:52:59 -0700
You should be able to replace this with pir_output_is( ..., todo = '...' );
Good idea; thank you. (I had forgotten about that syntax.)
-- Bob
Am Sonntag, 30. Juli 2006 04:50 schrieb Bob Rogers:
The attached patch detects cases where a continuation tries to enter a
runloop different from the one that is executing, and prints a warning
to stderr.
Looks very sane and appliable to me.
Thanks,
leo
-current_runloop_id, our_runloop_level);
+#endif
/*
* STACKED_EXCEPTIONS are necessary to catch exceptions in reentered
* run loops, e.g. if a delegate methods throws an exception
@@ -50,10 +63,14 @@
#endif
{
new_internal_exception(interpreter);
-interpreter-exceptions
On Saturday 29 July 2006 19:50, Bob Rogers wrote:
+local $TODO = 'runloop shenanigans';
+# stringification is handled by a vtable method, which runs in a second
+# runloop. when an error in the method tries to go to a Error_Handler
defined +# outside it, it winds up going to the inner
by
entering a secondary runloop (see src/pmc/delegate.pmc). The C code and the
extra runloop is acting as a Continuation barrier . . .
Ouch.
I've experimented some time ago to get at least exceptions working by
rewinding runloops also, but have failed so far.
IIUC, this is not even
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39988]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39988
The example:
.sub main :main
$P0 = get_hll_global ['Foo'], 'load'
runloop (see src/pmc/delegate.pmc). The C code and the
extra runloop is acting as a Continuation barrier. There are also some notes
about that in dan's blog.
I've experimented some time ago to get at least exceptions working by
rewinding runloops also, but have failed so far.
There's no way
From: Allison Randal [EMAIL PROTECTED]
Date: Sat, 22 Jul 2006 17:34:45 -0700
Bob Rogers wrote:
Two weeks ago I started writing something I had been thinking about for
a year now, tentatively called Continuations, Coroutines, And All That:
An informal introduction to creating
Bob Rogers wrote:
Two weeks ago I started writing something I had been thinking about for
a year now, tentatively called Continuations, Coroutines, And All That:
An informal introduction to creating advanced control structures in
Parrot. It is still mostly an outline, though -- it's hard to
to handle exceptional flow control?
I would ultimately like to see exceptions head down that road. But an
exceptions stack is a good first approximation, and is at least safer
than the current combined control+exceptions stack.
(CPS is, BTW, a part of Parrot internals in need of more documentation
post got buried, and I lost track of the fact that I hadn't replied.)
I would ultimately like to see exceptions head down that road. But an
exceptions stack is a good first approximation, and is at least safer
than the current combined control+exceptions stack.
(CPS is, BTW, a part
Applied as r13307.
Still needs some tweaking, e.g. fix the failing past.t, but good enough
for now.
leo
).
3. If the above pseudocode is implemented in PIR as a library
routine (as it easily could be), then the C substrate doesn't have to
keep track of exceptions that are in the process of being thrown.
4. In fact, and unless I have missed something additional that Perl
6 requires
On Sat, Jul 08, 2006 at 04:51:38PM -0700, Allison Randal wrote:
Chip did a fantastic job on the Exceptions PDD. With a few refinements,
I'm pronouncing it ready to implement.
montgomery-burns Excellent. /montgomery-burns
Mad properties to Allison for creating the first draft (updating is so
On Friday 14 July 2006 16:07, Bob Rogers wrote:
One way to ensure that a handler is not in scope
when invoked (though possibly not the only way) is to keep the list of
active handlers in a dynamic variable binding.
Here's what I don't understand. Why is there talk of a stack to keep track of
On Wednesday 12 July 2006 22:02, Vishal Soni via RT wrote:
This patch also introduces a Parrot API for the calling programs to
compile the code. Currently pugs uses immc_compile() call into IMCC.
Ideally Pugs should not be communicating with IMCC but with Parrot. This
new API will try to hide
which could be
added in future. Some e.g.
1. To throw Parrot exceptions instead of the String **error.
2. Possibly using Compiler PMC. (not sure on that yet)
Your suggestion is good and I will keep in mind.
These two functions are just a start for defining Compile API's.
Programming languages
Hi,
I would like to throw a Parrot Exception from IMCC to the calling
program instead of terminating IMCC when a parse error occurs.
Are there some example in Parrot as to how to throw a Parrot exception
and how to catch it?
-Vishal
Chip did a fantastic job on the Exceptions PDD. With a few refinements,
I'm pronouncing it ready to implement. We'll certainly work out more
details as we go along, but the best way to test the design is to start
on the code.
Allison
# New Ticket Created by Audrey Tang
# Please include the string: [perl #39715]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39715
Currently, if you use IMCC inside embedded parrot (eg. when compiling
via PGE), when
what do I know?
One question about push_dynscope, though: Is the
sub_to_call_when_scope_is_finally_inaccessible called when the
Parrot_Context is reclaimed? If so, why is that needed?
And getting back to exceptions, I'm seeing something that's pretty much like
the CL model, where
from the Lisp condition object). But would I really need to do anything
here? If an exception is caught by Lisp, why would Parrot even need to
know? S04 seems to require a great deal of bookkeeping for unhandled
exceptions, but would that necessarily impact Lisp handlers?
It's just a little hack
a Scheme compiler want to take advantage of that?
And getting back to exceptions, I'm seeing something that's pretty much like
the CL model, where the 'push_eh' opcode takes a _closure_, and the list of
handlers is its own array in the interpreter, not in the generic control
stack, and which
I was involved in the C++ standardization process, and argued for
resumption as opposed to termination only in exceptions. I was somewhat
of a pioneer, implementing C++ exceptions for my team to use before
commercial compilers had them. After all, why start a new project with
an old paradigm
to be in 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 necessary since
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
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
to get it wrong.
Seems to me that this is unavoidable. Exceptions are useful mainly
because they allow these drastic changes to normal control flow.
Writers of HLL code are relieved of at least some of this responsibility
by their compiler, but writers of PIR are exposed to the full complexity
[guest - Sat Apr 22 18:25:09 2006]:
The attached patch implements and tests divide by zero exceptions for
BigInt and Complex PMCs.
It also tests divide by zero exceptions for float PMCs. float and
integer PMCs are already properly handling divide by zero.
Thanks, applied.
Jonathan
to specify a thunk
that gets called when *entering* a dynamic context . . .
That too.
=back
=head1 IMPLEMENTATION
[I'm not convinced the control stack is the right way to handle
exceptions. Most of Parrot is based on the continuation-passing
style of
control, shouldn't
of Parrot, but is something you always intended
to write out later? What thoughts have you had on how exceptions
should work? All comments, suggestions, and contributions cheerfully
welcomed.
Allison
Here's what I hope is a contribution
had on how exceptions
should work? All comments, suggestions, and contributions cheerfully
welcomed.
Allison
The integer and floatval opcodes div, fdiv, and cmod now all throw a
E_ZeroDivisionError exception with the text Divide by zero. JIT/i386
and JIT/ppc are also adapted accordingly.
Updates for Integer, Float, Complex, BigInt PMCs are welcome.
leo
[EMAIL PROTECTED]
Date: Jan 10, 2006 3:57 PM
Subject: divide by zero exceptions
To: Perl 6 Internals perl6-internals@perl.org
The integer and floatval opcodes div, fdiv, and cmod now all throw a
E_ZeroDivisionError exception with the text Divide by zero. JIT/i386
and JIT/ppc are also adapted
are going to throw exceptions,
there needs to be a quick way of huffmanizing the scaffolding.
IIRC, use fatal decides between an exception being thrown and an
undef but ... value being returned.
IMO, it's important to coerce code into the same behavior: If a sub that
I call tries to throw an exception
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #37287]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37287
Subject: Re: [perl #22343] pdb + internal_exception = segfault
Date: Wed, 21 Sep
On Mon, 19 Sep 2005, Will Coleda wrote:
Good! [inline] isn't real Tcl, it's specific to partcl.
That test consists of the code:
inline PASM {
print ok\n
}
which should do the obvious thing. Odd that it's squawking about MMD_add.
It's very strange. It copied that snippet above
On Thu, 15 Sep 2005, Will Coleda wrote:
Done. All tests pass for tcl in leo-ctx5. (And with leo's recent fixes,
hopefully this means on all platforms for real this time. =-)
This should also fix the problem on windows, as the missing functions have
been uncommented, and are now available.
Good! [inline] isn't real Tcl, it's specific to partcl.
That test consists of the code:
inline PASM {
print ok\n
}
which should do the obvious thing. Odd that it's squawking about
MMD_add.
Can you 1) try this PIR, and 2) if that *works*, copy that tcl
snippet to examples/foo.tcl,
return system; [error]s are now exceptions)
- simplify quite a few cases where I can now simply let an
exception propagate instead of checking and branching;
- break future interoperability in other ways (what do you mean,
return is an exception?)
All in all, I think it's a step
return system; [error]s are now exceptions)
- simplify quite a few cases where I can now simply let an
exception propagate instead of checking and branching;
- break future interoperability in other ways (what do you mean,
return is an exception?)
All in all, I think it's a step in the right
in some ways (no longer odd two-
value return system; [error]s are now exceptions)
- simplify quite a few cases where I can now simply let an
exception propagate instead of checking and branching;
- break future interoperability in other ways (what do you mean,
return is an exception?)
All in all
On Wed, Jun 08, 2005 at 10:26:59PM +0100, The Perl 6 Summarizer wrote:
Missing MMD default functions
Dan was somewhat bemused to find that the MMD functions' defaults had
disappeared when he did a sync with subversion. He wondered whether this
was deliberate. Turns out that it
Jerry Gay [EMAIL PROTECTED] wrote:
On 5/12/05, Leopold Toetsch [EMAIL PROTECTED] wrote:
Just curious: what's the difference between these two:
E_IndexError,
E_IndexOutOfBoundsError,
the difference is very subtle ;)
Though so ;-)
... E_IndexOutOfBoundsError back to
Jerry Gay [EMAIL PROTECTED] wrote:
i'm converting many of the remaining internal_exception() calls to
real_exception() (except unimplemented ops, and other valid internal
exceptions)
Fine, thanks - applied.
Just curious: what's the difference between these two:
E_IndexError
On 5/12/05, Leopold Toetsch [EMAIL PROTECTED] wrote:
Jerry Gay [EMAIL PROTECTED] wrote:
i'm converting many of the remaining internal_exception() calls to
real_exception() (except unimplemented ops, and other valid internal
exceptions)
Fine, thanks - applied.
Just curious: what's
Given:
fail with configurable behavior
no fatal to make fail just warn
use fatal to make fail throw exceptions
A question came up on #perl6 for the following code:
no fatal;
class Foo {
use fatal;
method bar() { fail
Aaron Sherman skribis 2005-05-11 7:44 (-0400):
no fatal to make fail just warn
I thought it wouldn't warn, but instead silently return undef (an
unthrown exception).
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
been calling it).
use fatal to make fail throw exceptions
A question came up on #perl6 for the following code:
no fatal;
class Foo {
use fatal;
method bar() { fail; }
}
Foo.bar;
That is, bar() picks up
,
it will only turn undefs that were generated by fail calls into
exceptions. Other sorts of undefs will be returned as ordinary
undefs.
Likewise, in the bar() called under no fatal, it will only turn
exceptions that were generated by fail calls into undefs. Other
sorts of exceptions stay
On Wed, 2005-05-11 at 09:50, Luke Palmer wrote:
Oh, just to avoid further confusion: In the baz() called under fatal,
it will only turn undefs that were generated by fail calls into
exceptions. Other sorts of undefs will be returned as ordinary
undefs.
Ok, so let me try to get my head
() (except unimplemented ops, and other valid internal
exceptions)
before i send a list of patches for various files to the list, i'd
like to make sure this first patch is agreeable. i added a new
exception type (E_IndexOutOfBoundsError,) converted exceptions for the
array pmc, and modified it's test
At 8:07 AM +0100 12/10/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
... A scope exit
action is put in place on the control stack with:
pushaction Psub
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the
Dan Sugalski [EMAIL PROTECTED] wrote:
... A scope exit
action is put in place on the control stack with:
pushaction Psub
* What is the intended usage of the action handler?
* Specifically is this also ment for lazy DOD runs?
* How is the relationship to the Cpop_pad opcode?
Thanks,
leo
That ought to be enough for heavily used exception and for Perl6
control exceptions.
OTOH
e = new Exception
setattribute e, message, Pmsg
setattribute e, language, PLang
...
throw e
construct a full exception object.
Currently it is:
e[_message] = foo
e[_error]
e[_severity
Dan Sugalski [EMAIL PROTECTED] wrote:
At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Its in and named Creturncc since yesterday return with current
continuation.
Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks ago the first time.
I've asked for names of the
At 10:28 AM +0100 11/22/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
Its in and named Creturncc since yesterday return with current
continuation.
Hrm. The name's not right,
I've proposed ret_cc and returncc, about two weeks
I just noticed some test failures in the tcl suite.
Looks like the following code:
print HERE?\n
set_eh ignore
find_lex lexical, -1, var
clear_eh
Does the following at runtime:
3713 print HERE?\n
HERE?
3715 set_eh P20 - P20=Exception_Handler=PMC(0xf8eb30)
3717 find_lex P18, -1,
William Coleda [EMAIL PROTECTED] wrote:
I just noticed some test failures in the tcl suite.
exception syntax will change slightly.
set P4, P5[_invoke_cc]
especially these constructs (resumable handling).
Please use currently a local handler:
newsub ignore, .Exception_Handler, catch
pushing code should take care of building whatever
structure's needed to call into it. (Though other than making a
return continuation and changing the address to the address used in
the push_eh instruction I'm not sure we need to do anything else)
Throwing exceptions should be:
throw
I switched to local exception handler blocks, and am still getting the same
failure mode.
Of course, it works fine in a simple, single file example.
I've checked everything back in so you can take a look. Once you build tcl,
from the top level directory, try:
oolong:~/research/parrot_8075 coke$
Dan Sugalski [EMAIL PROTECTED] wrote:
Exceptions are not, by default, resumable.
Are there non-default resumable exceptions?
leo
do lexically scoped
exceptions I think we're better off with the restriction.
Good.
...Allowing
random invokables as exception handlers feels like it's likely to
have some subtle security or consistency problems associated with it,
though I can't give a good example at the moment.
Yep
Tim Bunce [EMAIL PROTECTED] wrote:
I guess the HLL compiler needs to ensure that for every push the
control flow will always pass through a matching pop.
Not necessarily. The handler is pushed onto the control stack. During a
context change (e.g. from a subroutine return), the previous context
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to take into the account is that return
continuations
Miroslav Silovic [EMAIL PROTECTED] wrote:
Hmm, the first thing to take into the account is that return
continuations can be promoted to the fully blown continuations.
Yes. But an exception handler is not a RetContinuation object. It's an
Exception_Handler object (also derived from
At 10:03 AM +0100 11/19/04, Miroslav Silovic wrote:
Dan Sugalski wrote:
It's also important for people writing these things to take into
account the possibility that their exit actions may potentially be
triggered multiple times, courtesy of the joys of continuations.
Hmm, the first thing to
to is:
push_eh label
with popping the top exception handler being:
pop_eh
I'm up for better names, too.
The push_ is okay but eh is meh. push_handler seems better, though
handler is terribly generic. If the documentation and comments use it
consistently only for exceptions, though
Dan Sugalski wrote:
Hmm, the first thing to take into the account is that return
continuations can be promoted to the fully blown continuations. This
should affect the handlers in the same way - so exception handlers
could have become arbitrary invokable objects at the point when the
exception
continuation. Leo brought this up but it got
lost in the firestorm. We've already got invoke Px and invokecc
Px along with the plain invoke and invokecc, but method calls aren't
as well-rounded, and tail-call versions would be useful as well.
With that out of the way, we should address exceptions
, too.
The push_ is okay but eh is meh. push_handler seems better, though
handler is terribly generic. If the documentation and comments use it
consistently only for exceptions, though, it could work.
-- c
exception handler being:
pop_eh
I'm up for better names, too.
The push_ is okay but eh is meh. push_handler seems better, though
handler is terribly generic. If the documentation and comments use it
consistently only for exceptions, though, it could work.
Throwcatch, so
ones are mostly unclassified real exceptions. Some of them
are internal errors, though. We'll have to go through the whole code and
convert most of the internal_exceptions to real_exception with an
appropriate exception type.
But what is actually an internal error? (are those
this-should-never
Kj [EMAIL PROTECTED] wrote:
But what is actually an internal error? (are those
this-should-never-happen situations that are not expected?
Yep.
A real exception is an exception within the VM that can be caught by user
programs (right?).
Yes.
... What should happen with an internal error?
Leopold Toetsch wrote:
Kj [EMAIL PROTECTED] wrote:
But what is actually an internal error? (are those
this-should-never-happen situations that are not expected?
Yep.
A real exception is an exception within the VM that can be caught by user
programs (right?).
Yes.
... What should
exceptions. Some of them
are internal errors, though. We'll have to go through the whole code and
convert most of the internal_exceptions to real_exception with an
appropriate exception type.
I suspect a real exception is a exception object that a user program
also can
create (so try/catch/finally
try/catch/finally blocks translate to Real Exceptions being
thrown).
Thanks,
Klaas-Jan
On Sat, Aug 14, 2004 at 12:26:23AM -0400, Michael Stone wrote:
: Finally, (and I'm just thinking about charset stuff here), exceptions
: frequently involve a bit of string processing. So if the
: charset/encoding code starts throwing exceptions, how do we write the
: string processing
for the same thing simply a I'm sorry, but
we don't support that situation?
However, before referencing that post, I have to ask a few questions to
try to deal with the current inadequacy of my understanding of Parrot
exception handling:
I have a basic idea of how exceptions work at the level
I'm trying to add exception handling support back in to tcl so I can
trap references to non-existant variables. This is using a recent, but
not just-now, cvs checkout.
I am currently getting a segfault if I enable the exception handler.
Running the code through -t, I see this near the end:
Will Coleda [EMAIL PROTECTED] wrote:
I'm trying to add exception handling support back in to tcl so I can
trap references to non-existant variables. This is using a recent, but
not just-now, cvs checkout.
I am currently getting a segfault if I enable the exception handler.
Running the code
Jens Rieks [EMAIL PROTECTED] wrote:
the attached test fails. It raises an exception in __init; if it is resumed
parrot exists after leaving __init.
I've now turned on again stacked exception handlers in runops(). With
this enabled, the test passes.
Thanks, added to object-meths.t
jens
leo
Hi,
the attached test fails. It raises an exception in __init; if it is resumed
parrot exists after leaving __init.
jens
use strict;
use Parrot::Test tests = 1;
output_is('CODE', 'OUTPUT', exceptions and different runloops);
_main:
newsub P0, .Exception_Handler, _eh
set_eh P0
Jens Rieks [EMAIL PROTECTED] wrote:
the attached test fails. It raises an exception in __init; if it is resumed
parrot exists after leaving __init.
Yep. s. the comment at src/interpreter.c:909.
jens
leo
Pete Lomax [EMAIL PROTECTED] wrote:
Null PMC access in set_integer_native()
This (and a lot of others) currently doesn't throw a real_exception, so
you can't catch it.
P0 = _eh()
That calls the exception handler directly as a sub.
PS getline always returns 0, and getfile
Hi,
Just fishing for comments..
I have been experimenting with error handling, using
P9 = 1
to force the error:
Null PMC access in set_integer_native()
(others too, such as Key not an integer! or Array index out of
bounds!).
I have found that:
newsub P0,
Michal Wallace [EMAIL PROTECTED] wrote:
Looking more at exceptions here... I
used to be able to put arbitrary
stuff in the _message slot of a
ParrotException... Now we can only use
strings. Is that permanent?
Depends on what exceptions finally are. But the standard entries like
_message
On Tue, Dec 02, 2003 at 10:05:46PM -0800, Michael G Schwern wrote:
Why not?
catch MyError with {
like( $ex, qr/Bad thing/ );
};
If there is no exception then then that test won't execute. It'd have to be
something like
try {
f();
fail(no
On Wed, Dec 03, 2003 at 10:20:03AM +, Fergal Daly wrote:
On Tue, Dec 02, 2003 at 10:05:46PM -0800, Michael G Schwern wrote:
Why not?
catch MyError with {
like( $ex, qr/Bad thing/ );
};
If there is no exception then then that test won't execute. It'd have to
Looking more at exceptions here... I
used to be able to put arbitrary
stuff in the _message slot of a
ParrotException... Now we can only use
strings. Is that permanent?
PythonException will need to be able
to hold an arbitrary python object.
I'm faking it by stuffing my PMC into
a string
101 - 200 of 306 matches
Mail list logo
