I've been hard pressed to find any examples of proper exception-raising
with Parrot
t/pmc/exception.t
Excellent, thank you.
On Thu, Nov 27, 2003 at 10:02:10PM +0200, Gabor Szabo wrote:
How am I going to test this ?
I came up with the following in the test script:
use Error qw(:try);
my $ex;
try {
f();
}
catch MyError with {
$ex = shift;
};
like($ex, qr/Bad thing happened/, 'successfully tested
I've been hard pressed to find any examples of proper exception-raising
with Parrot - reading back through the list in June/July I see that there
was some starts at implementing various exception related bits - has this
been at least semi-completed?
Andy Lester wrote:
How am I going to test this ?
Take a look at Test::Warn for warnings, and Test::Exception for errors.
I think qa.perl.org needs a listing of Test::* modules so that people
know what's available.
http://search.cpan.org/search?query=Test-mode=dist
lists many of them,
On Fri, 28 Nov 2003, Rafael Garcia-Suarez wrote:
Andy Lester wrote:
How am I going to test this ?
Take a look at Test::Warn for warnings, and Test::Exception for errors.
I think qa.perl.org needs a listing of Test::* modules so that people
know what's available.
lists many of them, but maybe a more comprehensive list would
categorize
them in 'test modules that use the Test::Builder framework', 'test
report utils'
(such as Test::Harness), 'mod_perl related tests', etc.
Iain Truskett and I are working on such a list right now. Actually,
he's done
Hi,
in a code I am writing right now http://yapcom.pti.co.il/
I used to croak from functions deep down.
When testing for such errors I used code like this in my
test script:
eval {
f(); # will croak
};
like($@, qr/Bad thing happened/, 'successfully tested bad thing');
Now I am
How am I going to test this ?
Take a look at Test::Warn for warnings, and Test::Exception for errors.
I think qa.perl.org needs a listing of Test::* modules so that people
know what's available.
xoa
--
Andy Lester
[EMAIL PROTECTED], AIM:petdance
http://petdance.com/
Nicholas Clark [EMAIL PROTECTED] wrote:
On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
When there are no events queued, for any thread, then we change branch
e_handler_foo back into branch label_foo, for speed.
Do we need to do this last bit explicitly? Or can we do it
On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
Actually, I'm thinking of something like the following... suppose the
original code is like:
label_foo:
loop body
branch_address:
branch label_foo
Add in the following:
e_handler_foo:
.local
Nicholas Clark wrote:
On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote:
Actually, I'm thinking of something like the following... suppose the
original code is like:
label_foo:
loop body
branch_address:
branch label_foo
Add in the following:
e_handler_foo:
.local
Jos Visser wrote:
There are a number of ops that could fail. Examples are find_lex but
also the various load and lookup ops. Options for handling failure are:
I would therefore vote for a feature where I (as language designer)
could indicate whether for instance a find_lex (but others too) fails
Jos Visser [EMAIL PROTECTED] writes:
There are a number of ops that could fail. Examples are find_lex but
also the various load and lookup ops. Options for handling failure are:
- Abort parrot
- Throw an exception
- Return a default (null) value
I think it is hard for the parrot designers
There are a number of ops that could fail. Examples are find_lex but
also the various load and lookup ops. Options for handling failure are:
- Abort parrot
- Throw an exception
- Return a default (null) value
I think it is hard for the parrot designers to decide what language
implementors want
On Mon, Aug 11, 2003 at 10:29:26AM +0100 it came to pass that Piers Cawley wrote:
Maybe this should be a global something...
Not global. Or, if it is global, it needs to be dynamically scoped
since you could possibly have different modules implemented in
different languages.
After some
Leopold Toetsch [EMAIL PROTECTED] wrote:
... Switching the whole op_func_table() or
ops_addr[] (for CG cores) is simpler,
If have it running now for the slow and the computed goto core.
The signal handler (interrupt code) switches the op_func_table (ops_addr)
and returns.
Then the next executed
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions
To be able to switch function tables, this then should become:
PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
Thus predereferncing the function pointer would place an offset
Sean O'Rourke wrote:
To be able to switch function tables, this then should become:
PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
Or is there a better way to do it?
Replacing the next instruction with a branch to the signal handler
(like adding a breakpoint) out of the question?
I
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
Replacing the next instruction with a branch to the signal handler
(like adding a breakpoint) out of the question?
I don't know, how to get the address of the next instruction i.e. the
PC above. Going this way would either mean:
- fill the
Sean O'Rourke wrote:
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
Replacing the next instruction with a branch to the signal handler
(like adding a breakpoint) out of the question?
I don't know, how to get the address of the next instruction i.e. the
PC above.
Thinking more of this: There is no
Sean O'Rourke wrote:
On Thu, 17 Jul 2003, Leopold Toetsch wrote:
PC = ((op_func_t*) (*PC)) (PC, INTERP); // prederef functions
To be able to switch function tables, this then should become:
PC = ((op_func_t*) (func_table + *PC)) (PC, INTERP);
Thus predereferncing the
Gregor N. Purdy [EMAIL PROTECTED] wrote:
#define DO_OP(PC,INTERP) \
(PC = ((INTERP-op_func_table)[*PC])(PC,INTERP))
The easiest way to intercept this flow with minimal cost is to
have the mechanism that wants to take over replace the interpreter's
op_func_table with a block of pointers
On Tue, Jul 15, 2003 at 10:15:57AM +0200, Leopold Toetsch wrote:
How is the described scheme supposed to work with JIT generated code ?
--
Jason
Gregor N. Purdy [EMAIL PROTECTED] wrote:
Benjamin --
#define DO_OP(PC,INTERP) \
(PC = ((INTERP-op_func_table)[*PC])(PC,INTERP))
The easiest way to intercept this flow with minimal cost is to
have the mechanism that wants to take over replace the interpreter's
op_func_table with a block
More fun to play with.
This is t/op/hacks_5.pasm:
newsub P0, .Exception_Handler, _handler
set_eh P0
div I10, 0
print not reached\n
end
_handler:
.include signal.pasm
print catched it\n
set I0, P5[_type]
neg I0, I0
ne I0, .SIGFPE, nok
print ok\n
nok:
end
Leopold Toetsch wrote:
[snip]
- When will we check, it there are events in the event queue?
If we check too often (between each two ops), it will slow things down.
If we don't check often enough, the code might manage to avoid checking
for events entirely.
I would suggest that every flow
Benjamin --
The trick is to find the cheapest possible way to get conditional
processing to occur if and only if there are events in the event
queue.
I'll only be considering the fast core here for simplicity. But,
if you look at include/parrot/interp_guts.h, the only thing of
interest there is
Some basic functionality is in. It needs for sure some tweaking, but it
seems to do the Right Thing.
Please have a look at the tests in t/pmc/sub.t, if these semantics and
the functionality is ok.
Have fun,
leo
Let the fun begin:
- in interpreter is a setjmp in front of calling the runloop
- die_hard longjmp's there and reenters the runloop in the exception
handler, if any. s. t/op/hacks.t.
Enough for today. Some spritzers[1] are waiting.
Have fun,
leo
[1] Grüner Veltliner + H2O + CO2 (inside the
Benjamin Goldberg [EMAIL PROTECTED] wrote:
Should the raise opcode produce resumable exceptions?
There is no problem with resuming after an opcode. E.g. when Craise
is:
invokecc Px # call exception handler
and the handler returns by Cinvoke P1 i.e. via the return
continuation, execution
Brent Dax wrote:
Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
# that it was nonfatal, and resume execution from just after the place
# it was thrown from.
The problem with that is that some exceptions are unresumable. For
example, exceptions
Leopold Toetsch [EMAIL PROTECTED] writes:
Dan Sugalski [EMAIL PROTECTED] wrote:
Exception handlers really strike me as anonymous lexically scoped
subroutines that get called with just one parameter--the exception
object. As far as the engine should be concerned, when an exception
is taken we
exceptions are unresumable. For
example, exceptions thrown in C code are difficult to resume from,
especially if they represent e.g. a segfault. Exceptions that
represent things like a file failing to open can be difficult to
handle if they're thrown from an inner routine--you'd need to know
where
At 5:08 PM -0700 6/26/03, Brent Dax wrote:
Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
that
# it was nonfatal, and resume execution from just after the place it was
# thrown from.
The problem with that is that some exceptions are unresumable
I'd like to layout some thougts, which get quite dim, when it comes to
threads. So there are a lot of questions.
1) Exceptions
There are 3 kinds of exception sources:
- hard: e.g. SIGFPE, SIGHUP. They get catched by signal handlers[1]
- soft: internal_exception()
- user: a Craise opcode signals
(... skipping (1) and (2) ...)
3) Threads
The underlaying model are posix threads if available. This implies
that all interpreter data are shared by default. So we'll need per
thread data: interpreter, prederef JIT code ...
Is 'the underlying model' the implementation of the OS running
K Stol [EMAIL PROTECTED] wrote:
(... skipping (1) and (2) ...)
3) Threads
Is 'the underlying model' the implementation of the OS running parrot (as
oppposed to a self-made system,
On Linux there are many threading libs. E.g. pth (GNU portable threads)
and pthread (POSIX threads). The latter
Yep. But when it comes to multithreading you can't assume the same
behavior on e.g. single or multiprocessor systems anway.
leo
Sounds like a user-land implementation should be default then, to guarentee
consistancy across hardware let alone machines. Software targeted for specific
uses can
there are a lot of questions.
1) Exceptions
There are 3 kinds of exception sources:
- hard: e.g. SIGFPE, SIGHUP. They get catched by signal handlers[1]
- soft: internal_exception()
- user: a Craise opcode signals a warning or die ...
Parrot does a longjmp(3), constructs an exception object[2], searches
This is more of a language thang, so I've redirected your message
there [here].
The most fundamental feature throwing an exception is that it transfers
program execution from the call site. Allowing the caller to resume
execution at that site is a very dangerous form of action at a distance.
stops throwing
exceptions.
So, maybe what's needed is a Cwarn catcher (CWARNCATCH... eew),
where Cwarn would throw an exception object with an attached
continuation. And of course, if a warning reached the top of the
stack without being caught, it would print itself and invoke its
way to
inhibit throwing an exception. That is, use program design rather than
language features to provide this functionality. e.g., a delegate:
However, I think the Ruby sopports resumable exceptions, so we need to
be able to do it at some level.
Matt
: Exceptions
Dan Sugalski wrote:
Piers Cawley wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
Okay, now that we're well on our way to getting
sub/method/whatever calling down and working, I want to point us
towards what I'm thinking of for exceptions.
Exception handlers really strike
thought I'd try and see how this would work. A toy example:
implementing saturated arithetic uses exceptions:
sub incr ( int $a is rw is checked )
{
$a++;
CATCH {
when IntegerOverflow { $a = int.max };
default { throw }
}
}
This would work for a single variable, but no extend it to do
Dan Sugalski wrote:
Piers Cawley wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
Okay, now that we're well on our way to getting
sub/method/whatever calling down and working, I want to point us
towards what I'm thinking of for exceptions.
Exception handlers really strike me as anonymous
Benjamin Goldberg:
# Concievably, we could then examine the exception, and maybe decide
that
# it was nonfatal, and resume execution from just after the place it was
# thrown from.
The problem with that is that some exceptions are unresumable. For
example, exceptions thrown in C code
handler gets called. If the Continuation object (the exception
handler) has a property of Cclass=* it catches all, if its
e.g. Cclass=math.* it catches all math exceptions.
When user code wants to do it all, it could have a Cclass=*
property and another e.g. UserClass property
(the exception
handler) has a property of Cclass=* it catches all, if its
e.g. Cclass=math.* it catches all math exceptions.
When user code wants to do it all, it could have a Cclass=*
property and another e.g. UserClass property for its own type
checking.
Exceptions
Piers Cawley:
Dan Sugalski [EMAIL PROTECTED] writes:
Exception handlers really strike me as anonymous lexically scoped
subroutines that get called with just one parameter--the exception
object.
So, we grab another register for 'current exception continuation'?
Then when code throws an
At 8:53 AM -0400 6/23/03, Piers Cawley wrote:
Dan Sugalski [EMAIL PROTECTED] writes:
Okay, now that we're well on our way to getting sub/method/whatever
calling down and working, I want to point us towards what I'm thinking
of for exceptions.
Exception handlers really strike me as anonymous
Dan Sugalski [EMAIL PROTECTED] writes:
Okay, now that we're well on our way to getting sub/method/whatever
calling down and working, I want to point us towards what I'm thinking
of for exceptions.
Exception handlers really strike me as anonymous lexically scoped
subroutines that get called
Okay, now that we're well on our way to getting sub/method/whatever
calling down and working, I want to point us towards what I'm
thinking of for exceptions.
Exception handlers really strike me as anonymous lexically scoped
subroutines that get called with just one parameter--the exception
Luke Palmer [EMAIL PROTECTED] writes:
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tue, 15 Oct 2002 14:33:28 -0400
I like the idea of this. The finer details, like returning what to
do, could be more elegant. But the extensibility idea is golden.
To change how certain exceptions
A brainstorm for your enjoyment, perusal, and general discussion...
SUMMARY
A proposal for an extension to the usual exception handling concept. The
concept detailed here provides a mechanism for handling exceptions in one
of three ways: changing the values being evaluated, setting the result
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tue, 15 Oct 2002 14:33:28 -0400
I like the idea of this. The finer details, like returning what to
do, could be more elegant. But the extensibility idea is golden.
To change how certain exceptions behave, a block simply changes the methods
is that certain common types of
exceptions could be handled in-place, instead of having to write exception
handlers. Perl5 already does some things like this, e.g. undefs become
empty strings and zeros when needed. I'm just suggesting formalizing the
process more so that custom in-place exception handlers
, at least not in the
general case. Restartable exceptions are very, very difficult to do.
(And parrot, alas, isn't going to be able to do them) You still need
to establish an exception handler at the spot you want to restart at
(which isn't free, alas) and you run into problems when you cross
Can you let me know if the way I think about exceptions is ok?
Thanks,
Daniel Grunblatt.
set I0,0
set I8,10
try
# User exception
catch !WRONG_NUMBERS, PRINT_WRONG
# Trying to catch an exception that was already catched.
catch !NOT_SUCH_FILE, NEVER_MADE_IT
print step
I've written a small exception demo in C and tried to avoid macros as
far as possible.
C code *may*, if it chooses, install a generic exception override,
and we'll have a routine for this. Something like:
EXCEPTION_OVERRIDE(exception_frame);
EXCEPTION_RELEASE(exception_frame);
Okay, here's a quick sketch of how exceptions are going to look.
First, we're going to treat them as essentially a sort of
upwards-only continuation. (Which they really are, so that's fine)
Exceptions are semi-fatal--they are *not* resumable. Too much
trouble. Maybe we'll lift
exceptions if I can)
Just make sure that we end up with something portable to be able to build
a miniparrot with just ANSI C. I assume that's still a design goal.
setjmp and longjmp, for better or worse, are ANSI C, so if we use
them conservatively (which we will) we're fine
On Tue, May 28, 2002 at 05:47:56PM -0700, Hong Zhang wrote:
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish it were otherwise but it's not. Too bad for us.
I think this statement
On Tue, 28 May 2002, Hong Zhang wrote:
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish it were otherwise but it's not. Too bad for us.
I think this statement is not very accurate.
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really unsafe on these platforms?
- According to the Unix
into the Well, *duh*, chuckehead category.
I think we'll be safe using longjmp as a C-level exception handler.
I'm right now trying to figure whether it's a good thing to do or
not. (I'd like to unify C and Parrot level exceptions if I can)
--
Dan
On Wed, 29 May 2002, Jerome Vouillon wrote:
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
Dan may have been referring to the fact that on some key platforms
(Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
use inside of threads.
Is it really
At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
What, you don't think we should wedge ourselves into the system MMU
At 5:47 PM -0700 5/28/02, Hong Zhang wrote:
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point
On Wed, May 29, 2002 at 03:23:41PM -0400, Dan Sugalski wrote:
At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
What,
at all.
I think we'll be safe using longjmp as a C-level exception handler.
I'm right now trying to figure whether it's a good thing to do or
not. (I'd like to unify C and Parrot level exceptions if I can)
That is my point. Even if libc does not have thread-safe longjmp, we
can easily make
At 2:24 PM -0500 5/29/02, David M. Lloyd wrote:
But in that case I agree with Dan's
analysis that flags should be used for signal handling just because
writing portable signal handling code that does much more (in a
potentially threaded environment) than that is very complicated.
Right, this is
Actually I'd been given dire warnings from some of the Solaris folks.
Don't use setjmp with threads!
I've since gotten details, and it's Don't use setjmp with threads
and do Stupid Things.
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the
On Wed, 29 May 2002, Hong Zhang wrote:
Actually I'd been given dire warnings from some of the Solaris folks.
Don't use setjmp with threads!
I've since gotten details, and it's Don't use setjmp with threads
and do Stupid Things.
I used to be at Sun. I knew those warnings too. If we
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it. In the worst case, write our own version.
..Or we could use setcontext/getcontext, could we not?
The setcontext/getcontext will be much worse than setjmp/longjmp.
The are more platform specific
setjmp/longjmp. The
are more platform specific than longjmp. And they don't work well inside
signal handler, just like longjmp.
I am assuming that we will _not_ use exceptions from within a signal
handler, as per Dan's statements.
When I was working on HotSpot JVM, we had some problems
At 15:22 on 05/29/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote:
I think we'll be safe using longjmp as a C-level exception handler.
I'm right now trying to figure whether it's a good thing to do or
not. (I'd like to unify C and Parrot level exceptions if I can)
Just make sure that we
When I was working on HotSpot JVM, we had some problems with getcontext.
They work 99.99% of time. We added many workaround for the .01% cases. I
believe the Solaris guys have been improving the code. I am not sure of
the current status.
Was that inside of a signal handler or just in
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish it were
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point, having considered the
alternatives, I wish
At 5:47 PM -0700 5/28/02, Hong Zhang wrote:
Okay, i've thought things over a bit. Here's what we're going to do
to deal with infant mortality, exceptions, and suchlike things.
Important given: We can *not* use setjmp/longjmp. Period. Not an
option--not safe with threads. At this point
similar kind of functionalities,
otherwise JIT will not be able to handle exceptions very fast. It will
be very awrkward to check for every null pointer and every function
return.
However, signal-compatible will be very difficult. It requries access
to ucontext, and most of thread package can
Non-yet-thrown exceptions must be a useful concept.
This is a bullet point from a list in Apo4 introducing
coverage of exception handling. Was Larry talking
about an exception object that hasn't yet been thrown?
Did he refer to this issue again anywhere else in the Apo?
--me
The included patch requires a new file t/op/exceptions.t, which tests basic exception
handling, in this case divide-by-zero.
Patch was generated against latest CVS, but it shouldn't matter -that- much.
-Jeff
[EMAIL PROTECTED]
diff --recursive -C 2 parrot_cvs/MANIFEST parrot/MANIFEST
***
Nicholas Clark wrote:
my $f = open $file or die "can't open $file";
is troublesome. It doesn't report *why* the file can't be opened.
[...] *flexible* exceptions are needed
The first version of RFC 88 didn't care what exception objects
were, but discussions in the errors ma
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Object neutral error handling via exceptions
=head1 VERSION
Maintainer: Glenn Linderman [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 28 Sep 200
Mailing List: [EMAIL PROTECTED]
Number: 119
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Object neutral error handling via exceptions
=head1 VERSION
Maintainer: Glenn Linderman [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 119
Glenn Linderman wrote:
Tony Olekshy wrote:
RFC 88 does say:
finally { ... }
Once the try block is entered, every finally block is
guaranteed to be entered before the try statement completes,
whether or not any exceptions have been raised since the try
Tony Olekshy wrote:
Yes, well, at this point I must re-iterate that (in light of reasons
for the existence of a try keyword that I have explained in other
messages), what you've written is the same as:
try { ... } finally { do_something(); }
Yes, they are equivalent.
And note that
can no doubt easily resolve.
RFC 88 does say:
finally { ... }
Once the try block is entered, every finally block is guaranteed
to be entered before the try statement completes, whether or not
any exceptions have been raised since the try block was entered.
I would take
Glenn Linderman wrote (in RFC 119 v2):
RFC 119 wants to make available to the catch block exactly the
same list of parameters supplied to throw. This is prevented
by RFC 88's stringification and concatenation of parameters.
Not quite true. You can't get exactly the same list, but
I made some mistakes in my previous comments. Here are the relevant
items:
Tony Olekshy wrote:
Glenn Linderman wrote (in RFC 119 v2):
RFC 88 uses the finally keyword as a subclause introducer for
the try statement. RFC 119 uses the except and always keywords
as subclause
a bunch of OO dereferencing syntax. $@
and @@ are great background tools, and have great characteristics to
assist in debugging, but using them shouldn't generally be necessary to
handle simple exceptions, so let's make it easy to handle simple ones,
by providing a simple list of parameters
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
object neutral error handling via exceptions
=head1 VERSION
Maintainer: Glenn Linderman [EMAIL PROTECTED]
Date: 16 Aug 2000
Last Modified: 22 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED
xception raised to signal an
assertion failure that typically indicates the inability of
an algorithm to complete the request it has been given".
Here at work we have algorithms that depend on throwing a
rather large number of light-weight exceptions [...]
Is this the only reason for
Peter Scott wrote:
Tony Olekshy wrote:
That's not what's proposed. The core and other users would
use classes derived from Error to raise errors. Other users
could even just Error itself. Exception is reserved for
exceptions that don't and shouldn't derive from Error.
I'm still
At 03:40 PM 8/16/00 -0500, Jonathan Scott Duff wrote:
Well, those of you writing "exception" RFCs be sure and include this
example in there somewhere (if it's relevant to your RFC of course).
Done.
I'm done thinking about exceptions now.
Some of us are hoping to do the same RSN :-
"JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes:
JSD On Wed, Aug 16, 2000 at 12:36:42PM -0700, Peter Scott wrote:
If you use a switch statement and want implicit rethrow (and I do), then
your exception handler somehow has to look inside the switch to see if an
exception was handled.
At 12:00 AM 8/16/00 -0600, Tony Olekshy wrote:
However, many people have broached topics such as conditional catch
blocks (such as those based on the exception's isa relationships),
multiple catch clauses with varying conditions, and post-finally
catch blocks.
I agree that we don't have a great
:
for (@PERL::EXCEPTIONS) {
print $_-file, "\t", $_-line, "\n";
}
Because there isn't a stack of exceptions; I'm talking about tracking the
movement of a single exception.
This feature gets repeatedly confused with the RFC 88 exception stacking
.
So is it syntactical sugar or something that can't be done otherwise?
Actually a lot of it is syntactic sugar, but the part that can't be done
otherwise is the implicit rethrowing of exceptions. It's interesting that
the folk who want to reuse existing keywords and switch seem to be the same
201 - 300 of 306 matches
Mail list logo
