perl6-language-errors  

Messages by Thread

• RFC 96 (v2) A Base Class for Exception Objects Perl6 RFC Librarian
• RFC 88 (v3) Omnibus Structured Exception/Error Handling Mechanism Perl6 RFC Librarian
• RFC 359 (v1) Improvement needed in error messages (both internal errors and die function). Perl6 RFC Librarian
  • RE: RFC 359 (v1) Improvement needed in error messages (both internal errors and die function). David Grove
• RFC 1 (v1) Improvement needed in error messages (both internal errors and die function). Perl6 RFC Librarian
• RFC 119 (v4) Object neutral error handling via exceptions Perl6 RFC Librarian
• RFC 119 (v3) Object neutral error handling via exceptions Perl6 RFC Librarian
• RFC 80 (v3) Exception objects and classes for builtins Perl6 RFC Librarian
• Re: $a in @b (RFC 199) David L. Nicol
  • Re: $a in @b (RFC 199) John Porter
• RFC 151 (v3) Merge C<$!>, C<$^E>, C<$@> and C<$?> Perl6 RFC Librarian
• RFC 151 (v2) Merge C<$!>, C<$^E>, C<$@> and C<$?> Perl6 RFC Librarian
  • Re: RFC 151 (v2) Merge C<$!>, C<$^E>, C<$@> and C<$?> Nathan Wiger
  • Re: RFC 151 (v2) Merge C<$!>, C<$^E>, C<$@> and C<$?> Peter Scott
• On RFC 88: Serendipity while throwing a string. Tony Olekshy
• RFC 88 version 3 draft 1 is available via http. Tony Olekshy
• $SIG{__DIE__} should be localized and cleared at the start of an eval block Bart Lateur
  • Re: $SIG{__DIE__} should be localized and cleared at the start of an eval block Peter Scott
  • Re: $SIG{__DIE__} should be localized and cleared at the start of an eval block Tom Christiansen
  • Re: $SIG{__DIE__} should be localized and cleared at the start of an eval block PerlDiscuss - Perl Newsgroups and mailing lists
• RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism Perl6 RFC Librarian
  • Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism Jonathan Scott Duff
  • Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism Peter Scott
  • Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism Jonathan Scott Duff
  • Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism Peter Scott
  • Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism Jonathan Scott Duff
  • Examples from RFC 88 redone using RFC 119 facilities [Was: Re: RFC 88 (v2) Omnibus Structured Exception/Error Handling Mechanism] Glenn Linderman
• RFC 63 (v4) Exception handling syntax Perl6 RFC Librarian
  • Re: RFC 63 (v4) Exception handling syntax Ilya Martynov
  • Re: RFC 63 (v4) Exception handling syntax Peter Scott
  • Re: RFC 63 (v4) Exception handling syntax Ilya Martynov
• Re: Exception handling [Was: Re: Things to remove] Tony Olekshy
  • Re: Exception handling [Was: Re: Things to remove] Glenn Linderman
• RFC 88 version 2 is available via http. Tony Olekshy
• Why except and always should be a seperate RFC. Tony Olekshy
  • Re: Why except and always should be a seperate RFC. Glenn Linderman
• Why "fatal" errors aren't special. Tony Olekshy
  • Re: Why "fatal" errors aren't special. Glenn Linderman
  • Re: Why "fatal" errors aren't special. Peter Scott
  • Re: Why "fatal" errors aren't special. Glenn Linderman
• Why $@ should be structured data. Tony Olekshy
  • Re: Why $@ should be structured data. Tony Olekshy
  • Re: Why $@ should be structured data. Glenn Linderman
• Checking error checking Michael G Schwern
• Re: RFC 119v2: Object neutral error handling via exceptions Tony Olekshy
  • Re: RFC 119v2: Object neutral error handling via exceptions Tony Olekshy
  • Re: RFC 119v2: Object neutral error handling via exceptions Glenn Linderman
  • Re: RFC 119v2: Object neutral error handling via exceptions Tony Olekshy
  • Re: RFC 119v2: Object neutral error handling via exceptions Tony Olekshy
  • Re: RFC 119v2: Object neutral error handling via exceptions Glenn Linderman
• Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Peter Scott
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring SystemCall Errors Tony Olekshy
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Jarkko Hietaniemi
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Tom Christiansen
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Jarkko Hietaniemi
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Tony Olekshy
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Peter Scott
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Jarkko Hietaniemi
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Tony Olekshy
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Chaim Frenkel
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Jarkko Hietaniemi
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Chaim Frenkel
  • Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors Michael G Schwern
• RFC 119 (v2) object neutral error handling via exceptions Perl6 RFC Librarian
• RFC 88: Description enhanced. Tony Olekshy
• On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Chaim Frenkel
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Chaim Frenkel
  • Re: On the case for exception-based error handling. Markus Peter
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Tom Christiansen
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Markus Peter
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Bennett Todd
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Bennett Todd
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Chaim Frenkel
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Chaim Frenkel
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Chaim Frenkel
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Markus Peter
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Markus Peter
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Markus Peter
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Markus Peter
  • Re: On the case for exception-based error handling. Glenn Linderman
  • RE: On the case for exception-based error handling. Brust, Corwin
  • RE: On the case for exception-based error handling. Peter Scott
  • RE: On the case for exception-based error handling. Markus Peter
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Peter Scott
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Tony Olekshy
  • Re: On the case for exception-based error handling. Glenn Linderman
  • Re: On the case for exception-based error handling. Tony Olekshy
• RE: Exception stack: let's use the @@ list. Brust, Corwin
  • RE: Exception stack: let's use the @@ list. Peter Scott
  • Re: Exception stack: let's use the @@ list. Tony Olekshy
  • RE: Exception stack: let's use the @@ list. Brust, Corwin
  • Re: Exception stack: let's use the @@ list. Tony Olekshy
  • RE: Exception stack: let's use the @@ list. Brust, Corwin
  • Re: Exception stack: let's use the @@ list. Tony Olekshy
  • Re: Exception stack: let's use the @@ list. Peter Scott
  • RE: Exception stack: let's use the @@ list. Brust, Corwin
  • Re: Exception stack: let's use the @@ list. Tony Olekshy
  • Re: Exception stack: let's use the @@ list. Peter Scott
  • Re: Exception stack: let's use the @@ list. Tony Olekshy
• RFC 88 v2 draft 5 is available via http. Tony Olekshy
  • Re: RFC 88 v2 draft 5 is available via http. Chaim Frenkel
• RFC 88: Possible problem with shared lexical scope. Tony Olekshy
  • Re: RFC 88: Possible problem with shared lexical scope. Glenn Linderman
  • Re: RFC 88: Possible problem with shared lexical scope. Dave Rolsky
  • Re: RFC 88: Possible problem with shared lexical scope. Tony Olekshy
  • Re: RFC 88: Possible problem with shared lexical scope. Dave Rolsky
  • Re: RFC 88: Possible problem with shared lexical scope. Tony Olekshy
  • Re: RFC 88: Possible problem with shared lexical scope. Peter Scott
  • Re: RFC 88: Possible problem with shared lexical scope. Tony Olekshy
  • Re: RFC 88: Possible problem with shared lexical scope. Peter Scott
  • Re: RFC 88: Possible problem with shared lexical scope. Tony Olekshy
  • Re: RFC 88: Possible problem with shared lexical scope. Peter Scott
  • Re: RFC 88: Possible problem with shared lexical scope. Chaim Frenkel
  • Re: RFC 88: Possible problem with shared lexical scope. Chaim Frenkel
  • Re: RFC 88: Possible problem with shared lexical scope. Dave Rolsky
  • Re: RFC 88: Possible problem with shared lexical scope. Chaim Frenkel
  • Re: RFC 88: Possible problem with shared lexical scope. Tony Olekshy
  • Re: RFC 88: Possible problem with shared lexical scope. Chaim Frenkel
  • Re: RFC 88: Possible problem with shared lexical scope. Tony Olekshy
  • RE: RFC 88: Possible problem with shared lexical scope. Brust, Corwin
• Draft 3 of RFC 88 version 2. Tony Olekshy
  • Re: Draft 3 of RFC 88 version 2. Dave Rolsky
  • Re: Draft 3 of RFC 88 version 2. Peter Scott
  • Re: Draft 3 of RFC 88 version 2. Tony Olekshy
  • Re: Draft 3 of RFC 88 version 2. Peter Scott
  • Re: Draft 3 of RFC 88 version 2. Tony Olekshy
  • Re: Draft 3 of RFC 88 version 2. Peter Scott
  • Re: Draft 3 of RFC 88 version 2. Tony Olekshy
  • Re: Draft 3 of RFC 88 version 2. Peter Scott
  • Re: Draft 3 of RFC 88 version 2. Chaim Frenkel
  • Re: Draft 3 of RFC 88 version 2. David L. Nicol
• RFC 88: What does catch "Foo" { } do? Tony Olekshy
  • Re: RFC 88: What does catch "Foo" { } do? Peter Scott
  • Re: RFC 88: What does catch "Foo" { } do? Tony Olekshy
  • Re: RFC 88: What does catch "Foo" { } do? Graham Barr
  • Re: RFC 88: What does catch "Foo" { } do? Tony Olekshy
  • Re: RFC 88: What does catch "Foo" { } do? Peter Scott
  • Re: RFC 88: What does catch "Foo" { } do? Tony Olekshy
  • Re: RFC 88: What does catch "Foo" { } do? Graham Barr
  • Structured exception handling should be a core module. Tony Olekshy
  • Re: Structured exception handling should be a core module. Peter Scott
  • Re: Structured exception handling should be a core module. Tony Olekshy
  • Re: Structured exception handling should be a core module. Peter Scott
  • Re: Structured exception handling should be a core module. Tony Olekshy
  • Re: Structured exception handling should be a core module. Peter Scott
  • Re: Structured exception handling should be a core module. Tony Olekshy
  • Re: Structured exception handling should be a core module. Peter Scott
  • Re: Structured exception handling should be a core module. Tom Christiansen
  • Re: Structured exception handling should be a core module. Peter Scott
  • Re: Structured exception handling should be a core module. Bart Lateur
  • Re: Structured exception handling should be a core module. Peter Scott
  • Re: Structured exception handling should be a core module. Tony Olekshy
• RFC 88 Exceptions, Errors, and Inheritance. Tony Olekshy
  • Re: RFC 88 Exceptions, Errors, and Inheritance. Peter Scott
  • Re: RFC 88 Exceptions, Errors, and Inheritance. Tony Olekshy
  • Re: RFC 88 Exceptions, Errors, and Inheritance. Peter Scott
  • Re: RFC 88 Exceptions, Errors, and Inheritance. Tony Olekshy
• RFC 63 Peter Scott
  • Re: RFC 63 Tony Olekshy
• RE: warn (was: yoda 2) Brust, Corwin

• Earlier messages