Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@>

> : That numerical part could then form the basis of the extended exception
> : mechanism. No, the programmer shouldn't memorize the error numbers:
> : there should be predefined constants, like
> : 
> : 	ERROR::filenotfound
> : 
> : which are numeric, and which could then be used for the catch switch.
> : Well, maybe drop the "ERROR::" part for brevity -- but not for clarity.
> 
> I think I agree with the folks that say errors should be caught by
> type, not by number.  Just as a for instance, you ought to able to
> write a simple handler that catches any ERRNO-style error.

Yup.  Enumerating errors/warnings is awkward because it says you know
beforehand all your possible errors/warnings.  It is very static and
non-extensible--having to recompile your Perl if you add/delete/change
errors/warnings isn't exactly dynamic.

-- 
$jhi++; # http://www.iki.fi/jhi/
        # There is this special biologist word we use for 'stable'.
        # It is 'dead'. -- Jack Cohen

• RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@> by Perl6 RFC Librarian
• Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@> by Bart Lateur
• Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@> by Peter Scott
• Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@> by Bart Lateur
• Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@> by Peter Scott
• Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@> by Bart Lateur
• Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@> by Larry Wall
• Re: RFC 151 (v1) Merge C<$!>, C<$^E>, and C<$@> by Jarkko Hietaniemi