Re: RFC 80 (v1) Exception objects and classes for builti
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 look silly to use "otherwise" there.
>
>You could make it so "catch" takes a list of 0 or more exception
>class names.
I like this. I will modify RFC 63 accordingly, although I note that RFC 88
is proposing something extremely similar.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 80 (v1) Exception objects and classes for builti
(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 {
}
With the catch block setting the lexical $@ to the exception.
Though, I'm sure that Larry will come up with a better synonym.
> "JP" == John Porter <[EMAIL PROTECTED]> writes:
JP> 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
>> };
JP> I'd like to recommend just "catch" instead of "otherwise",
JP> because sometimes you'll do this:
JP> try {
JP> # fragile code
JP> }
JP> catch {
JP> # handle other exceptions
JP> };
JP> And it would look silly to use "otherwise" there.
JP> You could make it so "catch" takes a list of 0 or more exception
JP> class names.
JP> --
JP> John Porter
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 80 (v1) Exception objects and classes for builti
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 --- but RFC 70 really only asks that it be possible to do Fatal.pm correctly, which it's currently not, because of builtins that return errors, but which cannot be wrapped. > Exceptions: the builtin die()s. RFC 80 was actually only thinking > about these, but clearly gets even more power if Fatal is used, > when a whole bunch more exception classes come into play. If you could sell that, I'd be one happy camper. But that's so much more radical than just making all error-reporting builtins wrappable, and so making it possible for Fatal.pm to finish the job, that I gave up any hope of trying to sell it. -Bennett PGP signature
Re: RFC 80 (v1) Exception objects and classes for builti
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 recommend just "catch" instead of "otherwise",
because sometimes you'll do this:
try {
# fragile code
}
catch {
# handle other exceptions
};
And it would look silly to use "otherwise" there.
You could make it so "catch" takes a list of 0 or more exception
class names.
--
John Porter
Re: RFC 80 (v1) Exception objects and classes for builti
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 >development, and even if it weren't, that switching all builtins to >throw exceptions is too radical a change. > >Rather, RFC 70 proposes that some (I hope!) subtle blemishes on >perl's innards get polished up a bit, so that all builtins that can >returns errors, can also be wrapped. If that fix were made, then the >already-available module Fatal.pm, included with perl releases for >some time now, could be made to work with all builtins, at which >point it would be a reasonable amount of additional work to make it >really easy to change this aspect of perl's behavior. I really hope >to be starting all my programs with > > use Fatal qw(:all); > >So, yes, there's a connection between RFC 70 and RFC 80, but I >submit that it's a little bit looser. If RFC 70 should prevail, then >Fatal.pm will step into the limelight, and _it_ should be made to >honor RFC 80 (or whatever ends up specifying the exception classes >for builtins). 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. Exceptions: the builtin die()s. RFC 80 was actually only thinking about these, but clearly gets even more power if Fatal is used, when a whole bunch more exception classes come into play. I like the way this is going. I'll fix up v2. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 80 (v1) Exception objects and classes for builti
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 builtins to throw exceptions is too radical a change. Rather, RFC 70 proposes that some (I hope!) subtle blemishes on perl's innards get polished up a bit, so that all builtins that can returns errors, can also be wrapped. If that fix were made, then the already-available module Fatal.pm, included with perl releases for some time now, could be made to work with all builtins, at which point it would be a reasonable amount of additional work to make it really easy to change this aspect of perl's behavior. I really hope to be starting all my programs with use Fatal qw(:all); So, yes, there's a connection between RFC 70 and RFC 80, but I submit that it's a little bit looser. If RFC 70 should prevail, then Fatal.pm will step into the limelight, and _it_ should be made to honor RFC 80 (or whatever ends up specifying the exception classes for builtins). -Bennett PGP signature
RFC 80 (v1) Exception objects and classes for builti
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 ABSTRACT
This RFC proposes that builtins that throw exceptions throw them as objects
belonging to a set of standard classes. This would enable an exception
type to be easily recognized by user code. The behavior if the exception
were not trapped should be identical to the current behavior (error message
with optional line number output to STDERR and exit with non-zero exit code).
=head1 DESCRIPTION
RFC 63 proposes a standard exception handling mechanism with the syntax and
semantics of Graham Barr's Error.pm. This allows code like
try {
# fragile code
} catch Exception::IO with {
# handle IO exceptions
} catch Exception::Socket with {
# handle network exceptions
} otherwise {
# handle other exceptions
};
Exceptions are objects blessed into classes the user names after the type
of exception; their attributes include text which will be be given to
C (one that won't be trapped) if the exception is uncaught. So
modules can throw exceptions without requiring that the user be trapping them.
RFC 70 proposes that all builtins throw trappable exceptions on
error. This RFC proposes that those exceptions be objects blessed into a
standard set of classes which can be checked for by the user. This is much
cleaner than
eval {
# fragile code
};
if ($@) {
# play guessing games with regexen on $@
# and hope that the error message doesn't
# change in the next release.
}
Yes, this proposal is very Javaish. I don't do much programming in Java
but I like the way it does this.
=head2 Classes
This is a strawman exception class hierarchy. The merits of this RFC do
not depend on this beign a good hierarchy, only on it being possible to
find a reasonable one. A common prefix like C is elided for
readability.
=over 4
=item Arithmetic
Divide by zero and friends.
=item Memory
C failed, request too large, that sort of thing.
=item Eval
A compilation error occurred in C, C, or C<(?{ ... })>. Possible
candidate for subclassing.
=item Regex
A syntax error occurred in a regex (built at run-time). Possible candidate
for subclassing.
=item IO
An I/O error occurred. Almost certainly should be subclassed, perhaps
parallel to the C hierarchy.
=item Format
Error in format given to C, C, octal/hex/binary number
etc. Could use a better name.
=item Thread
Some goof in threading.
=item Object
Tried to call non-existent method, that kind of thing.
=item System
Attempt to interact with external program failed (maybe it ran out of
process slots, that kind of thing).
=item Taint
Duh.
=item Reference
Attempt to dereference wrong kind of thing.
=item Recursion
Excessive subroutine recursion, maybe also infinite C or C
loops (although arguably they would throw a C exception).
=back
There are bound to be other categories that should be covered. This is
just to put meat on the bones. This is the province of librarians and
taxonomists; the fact that it's possible to argue endlessly about the
choices doesn't preclude coming up with good ones.
=head1 IMPLEMENTATION
This should not be construed as requiring that clearly fatal errors (e.g.
pointer corrupted) should be trappable, or throw O-O exceptions. Note that
compilation errors don't have to be classified.
Do we need to mention the C<$SIG{__DIE__} problem again?
=head1 REFERENCES
RFC 63, RFC 70,
C, L.
