Luke ~
These matters are covered at some length in RFC 88 and Apocalypse 4.
http://www.avrasoft.com/perl6/rfc88.htm
http://www.perl.com/pub/a/2002/01/15/apo4.html
Yours, c, Tony Olekshy
Luke Palmer wrote, at 2003-11-23 11:55:
I was reading over some code that used the MIDI module
. Is there any particular reason why multiple CATCH blocks can't
simply be queued in some fashion like multiple LAST blocks?
Yours, c, Tony Olekshy
Felicitations.
Yours, c, Tony Olekshy
aked concept of exception handling that (1) doesn't
work well in production, and (2) prevents the development of a
module-based mechanism that does work well. "All this talk about
exceptions" is just work toward nailing down the structural details
of the -language layer, to provide a reasonable working model of
the community perspective to the good folks over at -internals.
Yours, c, Tony Olekshy
Glenn Linderman wrote:
Tony Olekshy wrote:
Traditionally Perl has had both the "do" and the "eval" block
forms, the latter which traps, the former which doesn't.
In the perl 5 pocket reference 3rd edition page 63, it claims that
$@ is set to the result of an e
Glenn Linderman wrote:
Tony Olekshy wrote:
If we take this approach then we know exactly what the following
code will do.
{ my $p = P-new();
$p-foo and always { $p-bar };
except Error::IO { $p-baz };
}
We also know when the block propagates
Dan Sugalski wrote:
Tony Olekshy wrote:
I think we need to provide some way for developers to explicitly
specify predictable end-of-block cleanup (using something like an
always block or finally clause).
Attributes or other things stuck on the end of blocks strikes me as
a messy sort
se there's an exception
in the catch that hasn't been caught. There's a failure in the
failure handling. You want to report that, not catch it. (And if
you do want to catch it, just add clauses.)
Yours, c, Tony Olekshy
error codes any more, the
matter of the void context is moot: failures always throw.
Yours, c, Tony Olekshy
"David L. Nicol" wrote:
Tony Olekshy wrote:
If we take this approach then when you just want to casually say
my $f = open $file; always { close $f };
you can. I like that. In addition, [...]
How about "later" instead of "always"
Because: &
just test $@ directly (which works because of the rule that
$@ is always equal to $@[0]).
Both of the above results are implemented in the RFC 88 Perl 5
reference implementation (modulo syntax). There are more examples
at http://www.avrasoft.com/perl6/rfc88.htm#Examples
Yours, c, Tony Olekshy
trying to figure out how I might be able to make my
miniscule contribution to Perl 6 by writing the exception handling
FAQ. When I'm explaining
{ f() always { g() except Error::IO { h() } } }
I need to know: does h() get called if f() raised an Error::IO or
only if g() does?
Yours, c, Tony Olekshy
n
that should not be presented to the user but should be presented to
the developer and the logs (or not), all as appropriate to *your*
application.
Might that help?
Yours, c, Tony Olekshy
hat
tradition now?
If we work together on this we can make Perl 6's exception handling
something worth having worked on. If we throw a bunch of untested
ideas together we can only hope they work (at least I hope they work,
since Perl has been my favourite language for the last twelve years).
Now, shall we?
Yours, c, Tony Olekshy
Tony Olekshy wrote:
Damian Conway wrote:
Actually, I do agree that Perl 6 ought to provide a universal
"destructor" mechanism on *any* block. For historical reasons, I
suppose it should be Ccontinue, though I would much prefer a
more generic name, such as Ccleanup.
Pe
John Porter wrote:
Tony Olekshy wrote:
I think "always" should be part of an explicit statement, such
as "try", not some implied property of block structure introduced
by a dangling clause.
Why?
There's an old engineering joke about instructions that go on an
e
use that interacts reasonably well with the rest of Perl?
- What's the return value? With RFC 88 you can say:
my $r = try { f() } catch { 0 };
What are the syntax and semantics in the CATCH/POST case?
Perhaps something like:
my $r = do { CATCH { 0 } f() };
Hmm.
Yours, c, Tony Olekshy
en the closing curly brace in { ...; my $p = P-new(); ... }
is encountered, what happens to the object referred by $p?
Yours, c, Tony Olekshy
my $r = try { f() } finally { h() };
g();
should call h() whether or not f() throws; and if f() or h()
throw the exception should be propagated, otherwise $r should
be set, and g() should be called.
Yours, c, Tony Olekshy
cause
errors in error handling tend to make my code behave relatively poorly.
Yours, c, Tony Olekshy
PS: since we're completely off subject, can we continue this under
http:[EMAIL PROTECTED]/msg05604.html
http://www.avrasoft.com/perl6/try-tests.htm
Yours, c, Tony Olekshy
ann, Dave Rolsky, Corwin Brust, Jim Hoover,
and the Software Engineering Research Lab at the University of
Alberta, for your contributions to RFC 88.
Yours, c, Tony Olekshy
al hook parameter that specifies
the class into which to instantiate string throws.
Seems obvious in retrospect; we already had class and string,
why did E have to be class | object? Ah well, serendipity
is like that, I suppose.
Yours, c, Tony Olekshy
Peter Scott wrote:
Tony Olekshy wrote:
So if open, for example, can set $! without invoking die, then
$! and $@ must not be merged. As I read it, 151 would (as
currently promulgated) not meet my requirement for the unique
nature of a $@-style variable. I don't think overloading
Glenn Linderman wrote:
Tony Olekshy wrote:
You are oversimplifying by mixing the notions of exceptions
and errors, whether you are aware of their difference or not.
I am aware of the difference between errors and exceptions;
however, I firmly believe that exception handling
erly subclassed, the message ivars would be
useful, a unique tag would be specified, debug info would be
provided, c. But you get the idea.
And as you can see, when correctly coded, the concept of fatality
doesn't enter into it.
Yours, c, Tony Olekshy
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
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
with action at a
distance (unwinding semantics). It satisfies the first rule
listed under LMOTIVATION.
So there you have it. Try is not for Perl. Try is for You.
Yours, c, Tony Olekshy
Glenn Linderman wrote:
Tony Olekshy wrote:
Hi, it's me again. Not to be a pain, but RFC 88 does say:
Hey, no pain.
retry
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
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
Peter Scott wrote:
Tony Olekshy wrote:
I just don't think that with with respect to the infrastructure
mechanism per se, "fatality" should have anything to do with it.
In the end, that's a judgement call; that's what we get paid the
big bux for ;-)
I have reservat
Graham Barr wrote:
Peter Scott wrote:
Tony Olekshy wrote:
Graham Barr wrote:
I am of the opinion that only a class name should follow
catch. If someone wants to catch based on an expression
they should use
catch {
if (expr) {
}
else
of this in the back for their mind. Now they are
wondering just how robust some of their code is ;-) Nevertheless,
that's no argument for doing a bad job of how "try" et al work.
Yours, c, Tony Olekshy
onal Perl code will not longer
work traditionally, by default, is going to have a hard time with
many people, including me. That's why RFC 88 explicitly doesn't
suggest any such thing.
Yours, c, Tony Olekshy
Glenn Linderman wrote:
Tony Olekshy wrote:
Glenn Linderman wrote:
I'm now reaching the conclusion that RFC 88 is apparently
building more mechanism around item 2 to make it prettier for
use as a general exception mechanism. If so, I don't think
that is a good idea
Chaim Frenkel wrote:
Tony Olekshy wrote:
If no exception is in scope Perl should continue to generate and
propagate exceptions (die and $@) as it does now, so we don't
break tradition.
No, that should be the difference between die and throw. Die is
immediately fatal. (i.e. current
some simple data structure in $@ and @@, but whenever these
values are read, the are seamlessly and internally promoted to
first-class Exception objects. This way, the guts see internal
exceptions as simple data structures, and the user code sees
all exceptions as simple objects.
Yours, c, Tony
Glenn Linderman wrote:
Tony Olekshy wrote:
Glenn Linderman wrote (in RFC 119 v2):
It is not clear whether the finally clause is executed if
the try statement is exited via a goto or return, but the
statement is made that once a try statement is entered
# no snapshots anywhere "under" here in call stack.
}
It probably would be a good idea if you clean up some of these
misconceptions in your next release of 119, just so people don't
get the wrong idea about 88 ;-) Thanks.
Yours, c, Tony Olekshy
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
hould be handled by a separate
mechanism from that used for so-called "non-fatal" errors like
cant-open-file, where is where you stepped in. Said dialogue will
play itself out.
Yours, c, Tony Olekshy
g, not for replacing AUTOLOAD.
s/retry/resume/g
I'll try to make that more clear in 88v3d1.
Yours, c, Tony Olekshy
ts should be avoided unless the rules in
LUnwinding Semantics make sense to you and your target audience.
=head2 Walkthrough
throw Exception::IO "a message", tag = "ABC.1234", ... ;
Yours, c, Tony Olekshy
to change, not me. I'm certainly not trying to force Graham to
do anything, what he does is his business. If Graham decides that,
given the power and simplicity of RFC 88, he wants to change the Net::
API, you'll have to take that up with him, not me.
Yours, c, Tony Olekshy
Chaim Frenkel wrote:
Tony Olekshy wrote:
If you write this:
try { my $p = P-new;
my $q = Q-new;
}
finally { $p and $p-Done;
$q and $q-Done;
}
what happens if both constructors succeed, but $p-Done dies?
try
Peter Scott wrote:
Tony Olekshy wrote:
But, for simple scripts, Perl's inconsistency I just what I like.
Never thought I'd hear you say that :-)
Who, me? I'm a hopeless pragmatist. That's why I want try for big
programs. Pragmatically, that works better there. That's why I don't
Chaim Frenkel wrote:
Actually, why not simply unwind the call stack to the routine that
has the pragma active.
sub foo {use exception; baz()}
sub baz { throw "a fit" }
sub bar {
no exception;
foo();
}
Yes.
The
the usual quibbling about syntax, and how to make
to RFC read better, everything's on track here as far as I can
see.
Yours, c, Tony Olekshy
d possibly be consolidated.
Yes.
Especially if we do that auto-fatal under try thing some others
have written about. I have think about that some more before I
can try to say something intelligent, though. That would imply
dynamic scope for use fatal, and I think it should probably have
lexical scope.
Your
and handled (perhaps
with a null handler), or the program should terminate.
We agree. And the wrapper module is cool; hadn't thought 'bout that.
Yours, c, Tony Olekshy
"Brust, Corwin" wrote:
Tony Olekshy wrote:
Consider this case:
catch $@-{severity} eq "Fatal" = { ... }
Are you proposing to make @_ the exception stack in the catch
expressions too, as is:
nope, just Bwithin Ccatch.
catch grep $@-isa($_)
"Brust, Corwin" wrote:
From: Tony Olekshy [mailto:[EMAIL PROTECTED]]
That's well and good, but the source code syntax says it's a block,
not a sub. Am I supposed to spend the rest of my life asking myself,
"Wait, is this one of Corwin's special blocks?" ;-)
Chaim Frenkel wrote:
Dave Rolsky wrote:
Chiam Frenkel wrote:
Tony Olekshy wrote:
try { my $p = P-new;
my $q = Q-new;
...
}
finally { $p and $p-Done; }
finally { $q and $q-Done; }
Could you tell me why you would want two finallys
hree times in
RFC 88, once right in the ABSTRACT. I don't know what else I can say.
Tony Olekshy wrote:
Chiam Frenkel wrote:
The fact that something went wrong, doesn't mean that my 100
hour complex calcuation should be terminated. The fact that I
couldn't send an email message
the
program clear.
For many decades the telephone industry has *not* used normal phone
lines to send failure messages, because if the failure message is
that the line is down, well, you get the picture. Instead, they
have long relied on a seperate signalling channel. That's $@.
Yours, c, Tony Olekshy
):
try { my $err_code = Module::Foo(); }
finally { $err_code == $ok or
throw Exception "Can't Module::Foo.", code = $err_code }
this is, of course, just a slightly fancier version of
open ... or die ...;
Yours, c, Tony Olekshy
(heck, that doesn't even have to be restricted to
module authors; the creator of an insanely large program might do
it). The programmer can use this to decide whether to throw an
exception or return.
That's what I meant by $FATAL_MODE in my previous message.
Yours, c, Tony Olekshy
inappropriate,
this feature can simply be deleted, and the outer scope can be shared.
I added the following to RFC 88 + ISSUES + Lexical Scope:
The authors would prefer that try, catch, and finally blocks
share the same lexical scope.
Yours, c, Tony Olekshy
{ ++$i }. Just don't make what-
ever you come up with the default, ok ;-)
Yours, c, Tony Olekshy
ception handling is the right way to do errors.
All that RFC 88 does is make it take less code to do it right.
Of course, that's just my opinion, I could be wrong.
[Hmm, I was less convinced before I wrote this, than I am now, of
just that which I argue for herein. Thanks, Chiam, for helping me
make this stuff clearer to me.]
Yours, c, Tony Olekshy
Peter Scott wrote:
Tony Olekshy wrote:
Graham Barr wrote:
I am of the opinion that only a class name should follow catch.
If someone wants to catch based on an expression they should use
catch {
if (expr) {
}
else {
# rethrow the error
e, perhaps, to the vagaries of stack
unwinding), this feature can simply be deleted, and the outer
scope can be shared.
Yours, c, Tony Olekshy
Dave Rolsky wrote:
Tony Olekshy wrote:
try { fragile(); }
catch { my $caught = 1; }
finally { $caught and ... }
If all those pieces were in the same scope I think it would still
work like this (in Perl5-ish code):
{
try { fragile(); # It must be Italian
Peter Scott wrote:
Tony Olekshy wrote:
try { fragile(); }
catch { my $caught = 1; }
finally { $caught and ... }
It should work as though each pair of } ... { in between try { and
the end of the last finally or catch block isn't there. Storage
Peter Scott wrote:
Tony Olekshy wrote:
"An exception is not necessarily an error.\n" x 3;
Note that 'error' is a vague term for which you have a specific
meaning in mind here; be sure to give that definition where it's
important.
How 'bout something like, "an e
follwed by a comma-seperated list of class
names, the catch block is invoked only if the current is
an instance of one of the given classes. It is
syntactic sugar for:
catch grep { $@-isa($_) } @list { ... }
Yours, c, Tony Olekshy
esentation of the RFC 88 ideas for
a (hopefully) final v3.
I do want to leave in enough justification for the choices made,
so that the people who very well know will also know what details
we have already considered.
Yours, c, Tony Olekshy
parsable? Does Perl 5 do that in any cases?
If it's really unlikely, we should go back to the trap clause
(but I don't want to do that any more, I've found that the
expr for works very well in the examples in the RFC).
Yours, c, Tony Olekshy
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
Peter Scott wrote:
At 11:04 PM 8/18/00 -0600, Tony Olekshy wrote:
As currently promulgated, catch "Foo" {} will always catch,
because "Foo" is true. Will this cause confusion for developers
who meant to say catch Foo {}?
This is a good point, but I'm not about
$x = foo();
close F;
defined $x or return undef;
you can now write
try { foo(); }
finally { close F; }
Yours, c, Tony Olekshy
only if your exception handling mechanism
doesn't "encourage" you to drop exceptions of the floor.
Yours, c, Tony Olekshy
73 matches
Mail list logo
