This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Omnibus Structured Exception/Error Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy [EMAIL PROTECTED]
Date: 08 Aug 2000
Last Modified: 23 Aug 2000
Version: 2
Mailing List:
At 07:54 PM 8/24/00 +0400, Ilya Martynov wrote:
PRL Exceptions are objects belonging to some CException class. Cthrowing
PRL an exception creates the object; therefore, CEXCEPTION above is just a
PRL class name (possibly including some C::).
PRL
PRL The Cexception function is just syntactic
On Thu, Aug 24, 2000 at 03:37:59PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Omnibus Structured Exception/Error Handling Mechanism
Woohoo!
catch Alarm = { ... }
catch Alarm, Error = { ... }
catch $@ =~ /divide by 0/ = { ... }
The = here seems like useless syntax to me.
On Thu, Aug 24, 2000 at 10:47:45AM -0700, Peter Scott wrote:
But I initially wanted to do without the = ... unfortunately that would
require another keyword to handle the EXPR case and it didn't seem
worth it.
Not necessarily.
catch { EXPR } { ... } # probably not
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH "The first operation done on the return value of open() shall be defined()
JH or you shall regret your pitiful existence."? (a flag on the scalar coming
JH from open that makes any other op than defined() to die and defined() clears
JH the
On Thu, Aug 24, 2000 at 02:09:15PM -0400, Chaim Frenkel wrote:
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH "The first operation done on the return value of open() shall be defined()
JH or you shall regret your pitiful existence."? (a flag on the scalar coming
JH from open that
Tony Olekshy wrote:
Glenn Linderman wrote:
I do recall seeing this quote; however, replacing AUTOLOAD is a very
specific instance of resuming from or retrying a fault condition. And
even though a retry mechanism could be generalized from AUTOLOAD to
handling other conditions, it was
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
Tony Olekshy wrote:
There you have it. That's why RFC 88 uses structured data for $@.
That's a good argument, one that I have no quarrel with. As an
enhancement to eval/die, this would make it more flexible for checking
conditions. And with appropriate stringification, it is upward
Tony Olekshy wrote:
Other than for the except and always clauses, RFC 199 is very
similar to RFC 88. I like the idea behind except and always,
but I think the proposed implementation could be dramatically
simplified.
The first thing to realize is that just because 119 doesn't say
"try"
At 11:21 AM 8/24/00 -0700, Glenn Linderman wrote:
By building up a
non-fatal error handling technique on top the existing fatal error
handling technique, you are forcing code that assumes it will die to
behave differently, when you wrap a try block around it. Now it will only
"maybe" die.
Peter Scott wrote:
At 06:06 PM 8/24/00 -0600, Tony Olekshy wrote:
In fact, not only would I be pleased and honoured to author the
Perl 6 core Try.pm module, I'm already working on a Perl 5 standard
reference implementation.
Peter, I think we should make this approach more clear in RFC
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
JH Tough.
Not a nice attitude. The
Glenn Linderman wrote:
Tony Olekshy wrote:
Glenn Linderman wrote:
actually wrapping a bunch of code inside a try block
affects how that code reacts to die, thus affecting the
behavior of the program that previously used die to mean
terminate the program.
Hang on, this
14 matches
Mail list logo
