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
ring throws.
Seems obvious in retrospect; we already had and ,
why did have to be | ? Ah well, serendipity
is like that, I suppose.
Yours, &c, Tony Olekshy
implementation, in which
C does class hierarchies and $@->show works, is at:
http://www.avrasoft.com/perl6/try6-ref5.txt
Assuming no major problems with this draft are reported in the
next couple days, I'll publish this as the (presumably) final
version.
Yours, &c, Tony Olekshy
Peter Scott wrote:
>
> 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 sh
Peter Scott wrote:
>
> At 06:48 PM 8/24/00 -0600, Tony Olekshy wrote:
> >
> >I've read 151 a few times, and I don't understand how it can
> >impact the implementation of RFC 88 as a module. Please explain.
>
> If $@ and $! are mer
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.
>
> >Pete
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 p
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
> >
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 g
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,
> > w
100";
return $o + $my;
}
$foo = 300; $bar = 300;
try { $result = &really_delicate_code($foo, $bar); }
catch My100 => { ... error handling code here ... };
Well, not in production code, of course. There all the Exception
classes would be properly 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:
> >
> > 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
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 resum
flow control
is going on here. It signals intent to deal with action at a
distance (unwinding semantics). It satisfies the first rule
listed under L.
So there you have it. Try is not for Perl. Try is for You.
Yours, &c, Tony Olekshy
t, none of which
are show-stoppers. I'll get to their details asap. I've sent
this copy in its current state because the widening interest in
our little discussion in -erros means people are referring to
v1 of 88 in the RFC index, and v2 has major changes relative to
that.
Yours, &c, Tony Olekshy
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
> > > stat
ures, and the user code sees
all exceptions as simple objects.
Yours, &c, Tony Olekshy
Peter Scott wrote:
>
> At 10:13 AM 8/23/00 -0600, Tony Olekshy wrote:
>
> >Making throw a method of Exception just means we don't have to say
> >
> > throw Exception->new("Can't foo.", tag => "ABC.1234", ...);
> >
> &g
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
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 gener
hat since RFC 88 uses a "try" keyword to establish the
context in which a "finally" keyword is expected, and since
the my $foo examples above don't have such context, "always"
can probably be renamed "finally" without the parser getting
confused about RFC 88's finally.
And that would pretty much be my version of the "always" RFC.
Yours, &c, Tony Olekshy
etails and presentation of a clean but
extensible infrastructure mechanism that can be freely used by
all in the fashion to which they have been accustomed. We can
work out the syntactic sugar and command line flags as we go.
That, after all, is really the Perl way.
Yours, &c, Tony Olekshy
ject's C instance variable, and the new
Exception object is raised.
then you can say C, and the following tests both work:
catch $@->args->[1] eq "B" => { ... }
catch $@ =~ /B/ => { ... }
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 an
u want to, RFC 88 supports this
form already:
catch Exception::Fatal => { ... }
That's making an awful mess of the class hierarchy though.
Yours, &c, Tony Olekshy
"Brust, Corwin" wrote:
>
> Tony Olekshy wrote:
> >
> > Throw can't take no arguments because it's a constructor
>
> If $@ always contains an exceptions we don't need to construct one to
> throw.
Um, but, $@ doesn't contain an exception
ve.
It might be a good idea if the default snapshot method took a
dynamically scoped state variable into account, and maybe we could
just add it to a top-level try using the following syntax (already
proposed for other things in RFC 88):
try debug => 0, {
# 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
in, one just typically wouldn't use both techniques together.
Sorry to take time on this, but I'm not anti- or pro-OO. It's
just another technique, it works well for exceptions themselves,
it does not work well for exception handling itself (that is, as
I said, better off being pr
so why would you
want to automatically convert them to throw and catch? Remeber that
any RFC which proposes that traditional 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
denly realize that for years they *haven't* been
always been aware 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
"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,
> > "Wai
e complicated constructs should be avoided unless the rules in
L make sense to you and your target audience.
=head2 Walkthrough
throw Exception::IO "a message", tag => "ABC.1234", ... ;
Yours, &c, Tony Olekshy
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. Pragmatic
"Brust, Corwin" wrote:
>
> Tony Olekshy wrote:
> >
> > Consider this case:
> >
> > catch $@->{severity} eq "Fatal" => { ... }
> >
> > Are you proposing to make @_ the exception stack in the catch
> > expres
ing to go away, and everyone likes that.
The discussion here is about how to do the case where you do want to
do exception-based failure signalling. On that there seems to be
general agreement.
Yours, &c, Tony Olekshy
om/perl/rfc/rfc88v2d5.htm
POD as text: http://www.avrasoft.com/perl/rfc/rfc88v2d5.txt
Yours, &c, Tony Olekshy
hould be caught 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
hat would imply
dynamic scope for use fatal, and I think it should probably have
lexical scope.
Yours, &c, Tony Olekshy
as to
be a subroutine which takes a pre-built object or a string, like
this:
my $name = "Exception";
throw $name;
throw new Exception $name;
Peter once argued that he didn't want to new on every throw. I
agreed, and said, leave the matter of throwing string (lists) to
die. I still think that.
Yours, &c, Tony Olekshy
rt the other one.
Other than 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
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();
> }
Ye
get the picture. Instead, they
have long relied on a seperate signalling channel. That's $@.
Yours, &c, Tony Olekshy
are how you do that, because I don't want
to ignore it unless *I* say eval { ++$i }. Just don't make what-
ever you come up with the default, ok ;-)
Yours, &c, Tony Olekshy
ed to; if this is deemed 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
gt; "use Fatal" should set something that can be checked by any
> programmer (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
module doesn't do it, I'll
just keep doing the same thing I do now (if I'm writing code that
needs to be robust):
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
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;
> >
rcing
you 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
is is explained clearly three 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
> > > h
Chaim Frenkel wrote:
>
> Dave Rolsky wrote:
> >
> > Chiam Frenkel wrote:
> > >
> > > Tony Olekshy wrote:
> > > >
> > > > try { my $p = P->new;
> > > > my $q = Q->new;
> > > >
I'm going to both wrap my interface to it in trys, *and*
test its return codes (if any). I just want a way to make that
easier for me.
Structured exception 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:
> > >
> > > > try { fragile(); }
> > > > catch { my $caught = 1; }
> > > > finally { $caught and ... }
> > >
>
> It should work as though each pair of } ... {
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):
&
Dave Rolsky wrote:
>
> On Sun, 20 Aug 2000, Tony Olekshy wrote:
>
> > try { my $p = P->new; my $q = Q->new; ... }
> > finally { $p and $p->Done; }
> > finally { $q and $q->Done; }
> >
> > If P->new throws, then the second finall
built-in Exception-based Error class is no longer defined.
That was a bad idea waiting to die in the light of the other,
better, mechanisms now made available in the RFC (mainly,
the way C works now).
Thanks again to everyone.
Yours, &c, Tony Olekshy
y, catch, and finally blocks
share lexical scope (due, perhaps, to the vagaries of stack
unwinding), this feature can simply be deleted, and the outer
scope can be shared.
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
> > >
> &
glad to know that RFC 88, in the not quite ready
version two release, allows you do to just that.
Yours, &c, Tony Olekshy
Peter Scott wrote:
>
> At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
> >Peter Scott wrote:
> > >
> > > Dave Rolsky wrote:
> > > >
> > > > Tony Olekshy wrote:
> > > > >
> > > > > die
> > > > >
Peter Scott wrote:
>
> Dave Rolsky wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > die
> > >
> > > If argument isa "Exception", raise it as the new
> > > exception and die in the fashion that Perl 5 does.
> &g
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 {
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
> > excepti
=head1 TITLE
Structured Exception/Error Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 19 Aug 2000
Version: 2 (Draft 3)
Mailing List: [EMAIL PROTECTED]
Number: 88
=head1 DRAFT STATUS
This redaction has been modified to r
blish v2 in the next day or two, and then go
off and attempt to focus the presentation 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
time, and
> as long as I don't return from within the while, all is well.
I often find myself coding in the following manner:
open F, ... or die;
try {
}
finally { close F; }
and then going back and filling in the try block. Using this
technique has the advantage of closing F whether or not try
raises an exception.
I've added RFC 119 to RFC 88's REFERENCES, and queued up an
impact statement thereto.
Yours, &c, Tony Olekshy
to be 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
for works very well in the examples in the RFC).
Yours, &c, Tony Olekshy
new keywords: our
> objection to it is that it requires the programmer to insert
> C in every instance of by far the the most common
> type of clause (as well as not implementing the rich semantics
> of our daisy-chained finally clauses)."
>
> Reason: acknowledging many messages from people who thought
> this should be implemented with the new switch statement.
Excellent. It's in.
Yours, &c, Tony Olekshy
ctic sugar for:
> >
> > catch grep { $@->isa($_) } @list { ... }
>
> There is no difference between these two cases.
Agreed. I just want to emphasise both forms under DESCRIPTION.
I've changed it to the following.
catch Error::DB { ... }
When catch is follwed by a class name, the catch block
is invoked only if the current error is an instance of
said class. It is syntactic sugar for:
catch $@->isa($string) { ... }
catch Error::DB, Error:IO { ... }
When catch is 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
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
&
ne RFC for throwing and handling exceptions;
> another one for what goes in the exceptions.
Link is toast, given @@. The tag ivar is also in, because of
the namespace managing stuff. The object ivar is required for
wrapping non-Exception objects (if we keep that functionality
in, otherwise I'd still like to leave it in for Exceptions
that "relate-to" and object). And while severity and trace are
not strictly required by Exception, it seems reasonable to leave
them stubbed in for polymorphism across Errors and Exceptions.
Yours, &c, Tony Olekshy
ntrol should be distinguished from local
flow control, because $_[0] could be anything, whereas $@ is
always an exception, so it's clear what's going on.
@@ solves all these problems elegantly.
Yours, &c, Tony Olekshy
=head1 TITLE
Structured Exception Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 18 Aug 2000
Version: 2 (Draft 2)
Mailing List: [EMAIL PROTECTED]
Number: 88
=head1 DRAFT STATUS
Areas of development of this document which a
has a well defined semantics, and it can be easily avoided.
Here's one thing we could do. We could define a very simple
set of rules for the common but restricted case of a try
followed by an optional catch, followed by an optional finally.
That covers most cases. Then, we could refer to the
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > trap { $@->{message} =~ /divide by 0/ } catch { ... }
>
> I don't think you need another keyword here. Just support an
> expression argument to catch and you can do
>
> catch $@->{message
ry" functionality.
Yes, I believe that to do this correctly you need continuations,
which are beyond the scope of the exception handling RFCs (at
least to date).
Yours, &c, Tony Olekshy
te the error, like this:
$x = foo();
close F;
defined $x or return undef;
you can now write
try { foo(); }
finally { close F; }
Yours, &c, Tony Olekshy
Peter Scott wrote:
> Tony Olekshy wrote:
> >Peter Scott wrote:
> > > Tony Olekshy wrote:
> > > >
> > > > try { TryToFoo; }
> > > > catch { TryToHandle; }
> > > > finally { TryToCleanUp; }
> > >
=head1 TITLE
Structured Exception Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 2 (Draft 1)
Mailing List: [EMAIL PROTECTED]
Number: 88
=head1 ABSTRACT
This RFC describes a collection of changes and add
cord
{
for (my $attempt = 0; $attempt < 5; ++$attempt) {
my $fileName = &GetRecordFileName;
try { open REC, $fileName; }
catch "FILE-NO-OPEN" { next; }
# Work with the file...
return;
}
return undef;
}
Yours, &c, Tony Olekshy
{ throw }
.
. Other catch clauses go here, and are attempted only
. if $avoidCatches_JustUnwind is false after try.
.
finally {
# Can't be avoided. Don't use this clause otherwise.
}
Yours, &c, Tony Olekshy
,
while unwinding, for debugging purposes.
Yours, &c, Tony Olekshy
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > try { TryToFoo; }
> > catch { TryToHandleFailure; }
> > finally { TryToCleanUp; }
> > catch { throw "Can't cleanly Foo."; };
> >
> >In
odule given to others), and someone dumb
> deserves what they get for doing something so blatantly stupid.
I agree, we should not make it impossible, but I believe we should make
it relatively difficult to do accidentally (much like the forgotten
re-throw or function return code checking problems).
Yours, &c, Tony Olekshy
Executive summary: I no longer want catch blocks to "daisy chain"
after a exception is thrown in a catch block. Thanks to everyone
who has helped me see the light on this.
Peter Scott wrote:
>
> At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
> >
> > The proposed omn
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> >[snip]And the following output was generated:
> >
> > Exception
> >
> > $ = Try::throw('Exception') called from scott2.pm[8].
> > $ = main::pling('Test') called from
a list of which existing
> RFCs belong on the -objects list?
Please consider RFC 92, Extensible Meta-Object Protocol.
Also, the stuff going on in perl6-language-errors assumes a core
Exception class, for use by "use Fatal (:all)" or whatever. Since
this is, I believe, the first cas
e try. This can be avoided by using the
following synatx from the proposed omnibus Exceptions RFC:
try { }
except { $@->any(... $_[0] ...) } => catch { }
except { $@->any(... $_[0] ...) } => catch { }
catch { }
Is this a problem?
Yours, &c, Tony Olekshy
Jonathan Scott Duff wrote:
>
> Tony Olekshy wrote:
> >
> > The "try" is not necessarily for Perl's sake. It's for the
> > programmer's sake. It says, watch out, some sort of non-local
> > flow control may be going on here. It signals
lure is dropped on the
floor.
Using exceptions for failure signalling is a more robust software
engineering technique, but only if your exception handling mechanism
doesn't "encourage" you to drop exceptions of the floor.
Yours, &c, Tony Olekshy
ns, and post-finally
catch blocks.
I agree that we don't have a great handle on the flow-control semantics
for multiple catch blocks. We're working on it. But if we can come
up with some decent simple rules, then I see no reason to prohibit
careful use of more complex constructs.
Yours, &c, Tony Olekshy
"\t", $_->line, "\n";
> }
Yawn. That's the way RFC 88 v1 does it. Check it out.
We are trying to fix that problem. Nature abhors globals.
Yours, &c, Tony Olekshy
e sense that they are non-local flow control).
Yours, &c, Tony Olekshy
92 matches
Mail list logo
