. 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
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: &
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
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
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
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
{} finally {}. Finally. Finalization. Get it?
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
e 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
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
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
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
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:
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 88.
I'm
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 merged, then in code like
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
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
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
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", ...);
and it means throw isn't a new keyword, and that throw $@ can,
invoke
-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
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
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
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
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
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
=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 reflect Peter
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:
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.
If argument is a string, wrap it in a new Error
object, setting the me
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 severi
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} =~ /divide by 0/ { ... }
If it needs to be more
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 omnibus Exception
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 scott2.pm[4].
$ = main::bar('Test') called from scott1.pl[1].
$ = main
method calls to allow modules to effectively implement additional
low-level behaviour.
Yours, c, Tony Olekshy
ion 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
is caught.
Yours, c, Tony Olekshy
Piers Cawley wrote:
Tony Olekshy writes:
Peter Scott wrote:
An exception is an 'error'. That's already a vague concept.
I'll say it's vague. There are certainly uses for an exception to
trigger non-local success, not an error at all. In fact, there are
whole programming
Jonathan Scott Duff wrote:
On Mon, Aug 14, 2000 at 04:09:41AM -0600, Tony Olekshy wrote:
$@-CanFoo is an example of semantics that determines whether or
not the exception is caught; stringification may be an example
of semantics that comes into play when an exception is caught.
Ah
Evan Howarth wrote:
Tony Olekshy wrote:
Just be sure to arrange to handle exceptions while handling
exceptions.
Are you saying that the try-catch proposal automatically
handles exceptions thrown in catch and finally blocks?
Yes.
That's an interesting idea. Java, C++, and Delphi
Peter Scott wrote:
Tony Olekshy wrote:
When you want the first one, use try + catch.
When you want the second one, use eval, then manipulate $@.
Just be sure to arrange to handle exceptions while handling
exceptions.
Erk, people shouldn't have to use such radically different
, Tony Olekshy
"Randal L. Schwartz" wrote:
Tony Olekshy wrote:
Perl should be modified so that if C$ISA::Search (or equivalent)
Do you mean "$YOUR_PACKAGE::ISA::Search"
which is in the package "YOUR_PACKAGE::ISA"?
This would be the first time (to my k
at Peter's approach in RFCs 63 and 80 represents the
perspective that the exception is the key and handling is just
what you do with it, whereas my approach in RFCs 88 and 96 is
that handling exceptions is the key, and the exceptions are just
what you happen to be handling.
We should be able to do a pretty good job of putting these two
perspectives together into binocular vision (-; | ;-)
Yours, c, Tony Olekshy
ings we need, while taxing our notion
of what Perl OO looks like. So I guess you can chalk up my comment
to be "skeptical", at least for now.
Yours, c, Tony Olekshy
age attribute.
Or perhaps a formatted combination of a subset of the attributes,
as in RFC 96?
A Cfacility attribute was suggested to indicate what part of
perl is throwing the exception: IMO that is covered in the
exception class.
Agreed.
Yours, c, Tony Olekshy
I've moved this from perl6-language to perl6-language-flow.
Tony Olekshy wrote:
With the approach proposed in RFC 88 (Structured Exception
Handling Mechanism), you could write that as:
try {
} catch {
switch ($_[0]-name) {
case IO
{ ... }
}
}
finally { }
Yours, c, Tony Olekshy
tatement, and
it has not been cleanly caught.
* After processing all clauses, try unwinds (dies) iff any
exception wasn't cleanly caught.
An exception is considered to be "cleanly caught" if it was in
the try clause, and it triggered a catch clause, and no catch
or finally clause raised an exception.
Yours, c, Tony Olekshy
Yours, c, Tony Olekshy
Chaim Frenkel wrote:
[stuff about exception numbering]
Hmm, I thought I saw another exception RFC pass by.
Yup, RFC 88, Tony Olekshy [EMAIL PROTECTED]
Could you two folks get together and hash this out.
RFC 88 goes to some trouble to seperate exception handling from
exception objects
62 matches
Mail list logo
