Re: RFC 80 (v1) Exception objects and classes for builti

2000-08-10 Thread Bennett Todd
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

Re: RFC 80 (v1) Exception objects and classes for builti

2000-08-10 Thread Peter Scott
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

Re: RFC 80 (v1) Exception objects and classes for builti

2000-08-10 Thread John Porter
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 like to

Re: RFC 80 (v1) Exception objects and classes for builti

2000-08-10 Thread Bennett Todd
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 ---

Re: RFC 80 (v1) Exception objects and classes for builti

2000-08-10 Thread Chaim Frenkel
(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 { }