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
Felicitations.
Yours, &c, Tony Olekshy
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
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 };
> >
> >
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
"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
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
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
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
@@ => { ... }
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
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
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
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
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
"black box"). Finalization
is handled by try {} finally {}. Finally. Finalization. Get it?
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
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
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
.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
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
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
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
com/perl6/try6-ref5.txt
Regression Test http://www.avrasoft.com/perl6/try-tests.htm
Yours, &c, Tony Olekshy
at is suitable for error
handling, not for replacing AUTOLOAD.
s/retry/resume/g
I'll try to make that more clear in 88v3d1.
Yours, &c, Tony Olekshy
not divide-by-zero and
other such so-called "fatal" errors should 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
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
"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"?
>
>
extend ivars and control namespace?".
> Stringifying the object itself will yield the C attribute.
Or perhaps a formatted combination of a subset of the attributes,
as in RFC 96?
> A C 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
ivars are only visible via their accessor methods.
That's how that Prothos::Class module I mentioned in a previous
message (about RFC 92) works.
Yours, &c, Tony Olekshy
rl OO looks like. As far as I can
tell, RFC 95 doesn't do the things 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
om/oofaq2/body/typing.htm#S2.1
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 except
ite that as:
try {
} catch {
switch ($_[0]->name) {
case IO { ... }
case Socket { ... }
}
}
There is no need for a "global".
Let's take this discussion to [EMAIL PROTECTED],
and give it a new subject.
Yours, &c, Tony Olekshy
[EMAIL PROTECTED]
35 matches
Mail list logo
