At 12:59 PM 8/10/00 -0400, John Porter wrote:
>I'd like to recommend just "catch" instead of "otherwise",
>because sometimes you'll do this:
>
> try {
> # fragile code
> }
> catch {
> # handle other exceptions
> };
>
>And it would loo
(I'm not quite in favour. But assuming this flys...)
Why not use Damien's switch syntax. Much more powerful and the flow
is better controlled.
And why add another keyword. Just extend eval{} to accept two blocks.
eval {
}
catch {
}
finally {
}
Wi
2000-08-10-12:19:49 Peter Scott:
> Ah, got it. Now we have actually two types of error from builtins:
>
> Non-trapped (builtins return 0, undef, 1 :-) , n where n < # requests, etc).
> RFC 70 wants all these to be turned into optional exceptions if Fatal is used.
Ultimately, yes, that's my goal
Peter Scott <[EMAIL PROTECTED]>:
>
> try {
> # fragile code
> } catch Exception::IO with {
> # handle IO exceptions
> } catch Exception::Socket with {
> # handle network exceptions
> } otherwise {
> # handle other exceptions
> };
I'd l
At 09:44 AM 8/10/00 -0400, Bennett Todd wrote:
>2000-08-10-02:40:41 Perl6 RFC Librarian:
> > RFC 70 proposes that all builtins throw trappable exceptions on
> > error.
>
>Not quite. RFC 70 acknowleges that perl's current behavior is
>preferred by some very focal participants in the language's
>dev
2000-08-10-02:40:41 Perl6 RFC Librarian:
> RFC 70 proposes that all builtins throw trappable exceptions on
> error.
Not quite. RFC 70 acknowleges that perl's current behavior is
preferred by some very focal participants in the language's
development, and even if it weren't, that switching all bu
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception objects and classes for builtins
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 80
=head1
