aham Barr, Chaim Frenkel, Jonathan
Scott Duff, Glenn Lindermann, 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
com/perl6/try6-ref5.txt
Regression Test http://www.avrasoft.com/perl6/try-tests.htm
Yours, &c, Tony Olekshy
constructs that obfuscate
my attempts to get error handling right (such as they are) because
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
one of
which is not).
I'm just 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
e stack traceback and *other* information
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
to change that
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
"black box"). Finalization
is handled by try {} finally {}. Finally. Finalization. Get it?
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 C, though I would much prefer a
> > more
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
.htm#Unwinding_Semantics
- What about conditional CATCH blocks? What syntax can we
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
ot;scope". They're all about answering the following question:
When the closing curly brace in { ...; my $p = P->new(); ... }
is encountered, what happens to the object referred by $p?
Yours, &c, Tony Olekshy
ate trapped exceptions, because
you can always do it explicitly in every post/finally you write.
Others considered that to be a dangerous proposal, because of how
easy it would be to forget the re-throw in the common case.
The approach taken by RFC 88 was to work out a syntax and semantics
for multiple conditional catch clauses that still makes the easy
easy the helps make the hard possible. In the updated reference
implementation, I dynamically convert "except"s into "catch"s, which
seems to work, so far.
Yours, &c, Tony Olekshy
r = do { always { h() }; f() };
g();
or
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
the
impression some people think I want verbose code, or some sort
of impractial so-called "ivory tower" solution, but I'm really
just as lazy as you (probably lazier, but we don't want to debate
that here ;-)
Yours, &c, Tony Olekshy
@@ => { ... }
Of course, if you're only interested in the most recent
exception, skip the grep operations in these examples and
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
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 cl
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 };
> >
> >
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 stuc
t enough to terminate propagation, the
catching has itself to be "clean", otherwise 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
errors, "How many of us check for IO failures after prints? And if
you're writing a simple program you wouldn't want to have to, but
you would want the program to shut down after a failure if you don't
check." Also, since you're not returning 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 &qu
catch, or finally at all, if
one doesn't want to.
- This RFC does not require core Perl functions to use exceptions
for signalling errors.
The one thing we don't want on this front in the design of Perl 6
is some half-baked 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
Felicitations.
Yours, &c, Tony Olekshy
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 use
;2" } } LAST { "3" } };
What happens for each permutation of replacing "n" by die "n"?
7. 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
e sense that they are non-local flow control).
Yours, &c, Tony Olekshy
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
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
"\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
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
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
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
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
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
,
while unwinding, for debugging purposes.
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
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
Kai Henningsen wrote:
>
> Tony Olekshy wrote:
>
> > What if we implemented something like the following?
>
> Seems that the basic unwinder is
>
> > except { ... } => catch { ... }
>
> and everything else can be written in terms of this:
>
> &
l and enhance performance of function and
method calls to allow modules to effectively implement additional
low-level behaviour.
Yours, &c, Tony Olekshy
s the final act of the unwind processing".
By the way, this discussion has moved to perl-language-errors, so
the good folks here at perl-language-flow can concentrate on finding
silly words for other Perl flow-control constructs ;-)
Yours, &c, Tony Olekshy
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
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
=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
=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
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
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
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
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
=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
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
&
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
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
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
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:
>
> 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
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:
> >Peter Scott wrote:
> > > Tony Olekshy wrote:
> > > >
> > > > try { TryToFoo; }
> > > > catch { TryToHandle; }
> > > > finally { TryToCleanUp; }
> > >
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
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
Peter Scott wrote:
>
> At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
> >Peter Scott wrote:
> > >
> > > Dave Rolsky wrote:
> > > >
> > > > Tony Olekshy wrote:
> > > > >
> > > > > die
> > > > >
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:
>
> 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
> > >
> &
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
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
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
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):
&
Peter Scott wrote:
>
> > > Tony Olekshy wrote:
> > >
> > > > try { fragile(); }
> > > > catch { my $caught = 1; }
> > > > finally { $caught and ... }
> > >
>
> It should work as though each pair of } ... {
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
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
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
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;
> >
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
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
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
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
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
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
hat would imply
dynamic scope for use fatal, and I think it should probably have
lexical scope.
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
om/perl/rfc/rfc88v2d5.htm
POD as text: http://www.avrasoft.com/perl/rfc/rfc88v2d5.txt
Yours, &c, Tony Olekshy
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
"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
"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
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
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
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
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
Chaim Frenkel wrote:
>
> Dave Rolsky wrote:
> >
> > Chiam Frenkel wrote:
> > >
> > > Tony Olekshy wrote:
> > > >
> > > > try { my $p = P->new;
> > > > my $q = Q->new;
> > > >
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
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
ures, and the user code sees
all exceptions as simple objects.
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
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
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
"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
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
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
1 - 100 of 123 matches
Mail list logo
