Draft 3 of RFC 88 version 2.
=head1 TITLE
Structured Exception/Error Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy [EMAIL PROTECTED]
Date: 19 Aug 2000
Version: 2 (Draft 3)
Mailing List: [EMAIL PROTECTED]
Number: 88
=head1 DRAFT STATUS
This redaction has been modified to reflect Peter Scott's comments
through 2000-08-18.
Areas of development of this document which are not yet complete as
of this draft are annotated with the -- glyph. This version is not
intended to be the final redaction of this RFC, as there remains
opportunity to enhance the focus and clarity of this document to
the benefit of the reviewers hereto.
The inclusion of a definitions section for terms like propagate,
unwind, exception, and error is under consideration.
This RFC needs to better explain the purpose behind factoring Error
from Exception, an to more clearly explain the matter of RFC 80.
Production editing and spell checking have not been done yet.
=head1 ABSTRACT
"The Encyclopedia of Software Engineering" [ESE-1994] says (p.847):
Inevitably, no matter how carefully a programmer behaves when
writing a program and no matter how thoroughly its verification
is carried out, errors remain in the program and program
excecution may result in a failure. [...] The programming
laguage may provide a framework for detecting and then handling
faults, so that the program either fails gracefully or continues
to work after some remedial action has been taken to recover
from the error. Such a linguistic framework is usually called
exception handling.
This RFC describes a collection of changes and additions to Perl,
which together support built-in base classes for Exception and
Error objects, and exception and error handling code like this:
exception 'Error::DB';
try {
throw Error::DB "a message", tag = "ABC.1234", ... ;
}
catch Error::DB { ... }
catch Error::DB, Error:IO { ... }
catch $@-{message} =~ /divide by 0/ { ... }
catch { ... }
finally { ... }
Any exceptions that are raised within an enclosing try, catch, or
finally block, where the enclosing block can be located anywhere up
the subroutine call stack, are trapped and processed according to
the semantics described in this RFC.
The new built-in Error base class is designed to be used by Perl for
raising exceptions for failed operators or functions, but this RFC
can be used with the Exception and Error base classes whether or not
that happens.
Readers who are not familiar with the technique of using exception
handling to handle errors should refer to the CONVERSION section
of this document first.
=head1 DESCRIPTION
exception 'Error::App::DB::Foo';
Makes Error::App::DB::Foo into a class that inherits from the
built-in Exception class.
If the given name matches /::/, something like this happens:
@Error::App::DB::Foo::ISA = 'Error::App::DB';
and all non-existent parent classes are automatically created as
inheriting from their parent, or Exception in the tail case. If
a parent class is found to exist and not inherit from Exception,
a run-time error exception is raised.
If the given name does not match /::/ (say it's just 'Success'),
this happens instead:
@Success::ISA = 'Exception';
This means that every exception class isa Exception, even if
Exception:: is not used at the beginning of the class name.
The exception function can also take optional arguments, along
the lines of
exception 'Error_DB', isa = "Error::App";
which results in something like
@Error_DB::ISA = 'Error::App';
Other options may possibly be given to Cexception to control
things like the raise-time stack traceback.
throw Error::DB "a message", tag = "ABC.1234", ... ;
Throw is both a class and an instance method of the build-in
Exception class. The indirect object syntax is used to make the
throw imperitive. As a class method, it is syntactic sugar for:
die Error::DB-new(
message = "a message", tag = "ABC.1234", ...);
As an instance method it is syntactic sugar for copying over
any values given as arguments, and then effecting Cdie $self.
This allows Cthrow $@ to be used to re-raise exceptions.
Note that a derived class can override its constructor to
preprocess the optional arguments, so that (for example) tags
are parsed out of the message, which allows something like this
to work for developers who prefer it (such as the author):
throw MyError "ABC.1234: A message.";
This also illustrates why the message is a required argument
to the throw method. It should not have to be more complicated
than that to raise an exception of a given type with a given
annotation, in common use. One should not have to always add
"message =" just for that.
try { ... } catch EXPR { ... } finally { ... }
A try
Re: RFC 88 Exceptions, Errors, and Inheritance.
Peter Scott wrote: Tony Olekshy wrote: That's not what's proposed. The core and other users would use classes derived from Error to raise errors. Other users could even just Error itself. Exception is reserved for exceptions that don't and shouldn't derive from Error. I'm still having a hard time with this. Maybe everyone else sees it and can explain it to me. All I see is, you have a mechanism for implementing non-local flow control. The reason the control flow skipped is surely opaque and irrelevant to the mechanism? What the program decides to do with that exception, likewise. Success and failure are more or less arbitrary interpretations we place on these exceptions. I've taken out the concept of a built-in Error class. It turns out that I really just don't want to have to write throw Exception::Error::App::DB tag = "ABC.1234", message = "Can't write to table $table."; instead of throw Error_DB "ABC.1234: Can't write to table $table."; RFC 88 (now, but not until recently) lets me do that via inheritance, so I now gladly turn all the other built-in error stuff over to RFC 80 ;-) No. I want Error to be able to be extended, over the evolution of Perl 6, to include anything that is deemed suitable for error handling. I don't want any of that to interfer with base Exception functionality. Ok, so now I may have to go and turn off something new in a light-weight class. I can live with that, as long as RFC 80 keeps this in mind. Yours, c, Tony Olekshy
Re: Draft 3 of RFC 88 version 2.
On Sat, 19 Aug 2000, Tony Olekshy wrote: die If argument isa "Exception", raise it as the new exception and die in the fashion that Perl 5 does. If argument is a string, wrap it in a new Error object, setting the message ivar to the given string, and raise that instead. Actually, the Perl5 die takes a list as its argument and does join '', @_ to it to make the actual error message. If argument is anything else, raise a run-time exception. So this probably shouldn't be the case. /*== www.urth.org We await the New Sun ==*/
Re: Draft 3 of RFC 88 version 2.
At 09:22 PM 8/19/00 -0500, Dave Rolsky wrote: On Sat, 19 Aug 2000, Tony Olekshy wrote: die If argument isa "Exception", raise it as the new exception and die in the fashion that Perl 5 does. If argument is a string, wrap it in a new Error object, setting the message ivar to the given string, and raise that instead. Actually, the Perl5 die takes a list as its argument and does join '', @_ to it to make the actual error message. If argument is anything else, raise a run-time exception. So this probably shouldn't be the case. This sounds alright; there's something very self-defeating about raising a run-time exception from dying badly, if you see what I mean. So the third case goes and the second one becomes, args are stringified and joined on '', etc. -- Peter Scott Pacific Systems Design Technologies
Re: Draft 3 of RFC 88 version 2.
Peter Scott wrote: Dave Rolsky wrote: Tony Olekshy wrote: die If argument isa "Exception", raise it as the new exception and die in the fashion that Perl 5 does. If argument is a string, wrap it in a new Error object, setting the message ivar to the given string, and raise that instead. Actually, the Perl5 die takes a list as its argument and does join '', @_ to it to make the actual error message. If argument is anything else, raise a run-time exception. So this probably shouldn't be the case. This sounds alright; there's something very self-defeating about raising a run-time exception from dying badly, if you see what I mean. Yes! That's why v1 of RFC 88 didn't do that. Thanks, Dave. So the third case goes and the second one becomes, args are stringified and joined on '', etc. It now reads: If passed a single argument that isa "Exception", raise it as the new exception and die in the fashion that Perl 5 does. Otherwise, the arguments are stringified and joined with C'' (as in Perl 5), the resulting string is wrapped up in a new Exception object (setting the message ivar to said string), and the new Exception object is raised. Yours, c, Tony Olekshy.
Re: RFC 76 (v1) Builtin: reduce
Array and placeholder indices both start at *zero*! Array and placeholder indices both start at *zero*! Array and placeholder indices both start at *zero*! Array and placeholder indices both start at *zero*! - Original Message - From: "Damian Conway" [EMAIL PROTECTED] To: "Jarkko Hietaniemi" [EMAIL PROTECTED]; "Larry Wall" [EMAIL PROTECTED]; "Jeremy Howard" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, August 19, 2000 3:22 PM Subject: Re: RFC 76 (v1) Builtin: reduce Except that Perl 6 people will know all about numbered parameters, so they will write: @out = sort ^2 cmp ^1, @in; and it will work just as they expect! As long as they expect it to fail miserably! :-( Now, go home and write it out 100 times: "Array and placeholder indices both start at *zero*!" Damian
Re: RFC 76 (v1) Builtin: reduce
Now, go home and write it out 100 times: "Array and placeholder indices both start at *zero*!" Array and placeholder indices both start at *zero*! Array and placeholder indices both start at *zero*! Array and placeholder indices both start at *zero*! Array and placeholder indices both start at *zero*! Cunning devil. Base 2! Damian
Re: Extended Regexs
/\A(?s:(?!and).)*\Z/
/pattern returned from ${\some_function} as part of a regex/
/match any of (${\join'|',@list}) here/
I am not saying these things can't be done, in fact I was saying they can
but was rather asking what should be made easier?
Perhaps I was suggesting: "none of the above".
:-)
Damian
Re: RFC 76 (v1) Builtin: reduce
I think this does the right thing too:
@out = sort ^0 cmp ^a, @in;
Since numbered placeholders have higher priority than named, it
should create the function
sub ($, $a) { $_[0] cmp $_[1] }
When the curry is evaluated, the a: parameter is bound to $_[1]
and the b: parameter fills in $_[0].
Yes.
If this code is used instead:
@out = sort ^1 cmp ^a, @in;
Then a different function would be generated:
sub ($a, $) { $_[1] cmp $_[0] }
But the code still works.
Yes.
That's kind of interesting -- the numbered placeholders define the
ordering for the parameters passed anonymously, while the named
placeholders define ordering for the parameters passed by keyword.
I keep feeling like there's something here to trip on, but I
can't find it.
Well, this:
@out = sort ^a cmp ^0, @in;
fails very badly (but could generate a "parameter $b not used in call to
curried expression" warning under Cuse strict 'parameters').
Also:
@out = sort ^z cmp ^a, @in;
is counterintuitive (but would also generate a warning)
And both:
@out = sort ^l cmp ^0, @in;
and
@out = sort ^1 cmp ^O, @in;
are very nasty in a sans serif font :-)
P.S. What the heck kind of sort is that?! O(N**3) random permutation
sort?
Yup. Don't you just love it?! :-)
Re: Maximum length input lines
In reply to your message from the not too distant future: next Saturday AD Reply-to: [EMAIL PROTECTED] Return-receipt-to: [EMAIL PROTECTED] Organization: a) Discordia b) none c) what's that? Content-Typo: gibberish, charset=ascii-art Date: Sat, 19 Aug 2000 20:50:44 -0400 From: Jerrad Pierce belg4mit I do believe thbis is one of the reasons sysread is there perldoc -f sysread -- * __* . \ | / .. . . . ((_ _ . . . -- / \ -- .. . +. . _/\ oo. | * . . . * / ;M\_ . ..oo. . .. . /\. / :IMM\ ....oo. Jerrad Pierce /\ / \ / ;IIWMM ..oo... 209 North Street +/ \ / \ . / ;WM ...o... Randolph, MA 02368/ \ \ ___/ :;IWM oooo.../\\ / :: ;;IIIMI .ooo.http://www.pthbb.org /\ \ : :::;IIIM ..ooo __ || || ::.:: MOTD on Sat Aug 19 2000 12 23: "Dear Lord, give me chastity and self-restraint... but not yet, O Lord, not yet!" -Saint Auguistine A.D. 354-430
Re: Maximum length input line
In reply to your message from the not too distant future: next Saturday AD Reply-to: [EMAIL PROTECTED] Return-receipt-to: [EMAIL PROTECTED] Organization: a) Discordia b) none c) what's that? Content-Typo: gibberish, charset=ascii-art Date: Sat, 19 Aug 2000 20:59:26 -0400 From: Jerrad Pierce belg4mit Au contraire; sysread reads exactly the number of characters requested; what I want is a way for programs that do FH all over the place to be protected if someone throws a gargantuan number of characters at FH without a newline. The $/ = ref_to_int feature is exactly the kind of feature I was expecting to do this and I was disappointed that it didn't. True but sysread is non-blocking, so it can be used for this. Also, in the event you are dealing with certain types of data-streams, you could set $/ to a character which should occur in the data. For example if you're reading a potentially large English language stream (w/o newlines), set $/ to e. It's a pain yes, but that's what you get for having control ;-) Just pointing out there are "ways around this" -- * __* . \ | / .. . . . ((_ _ . . . -- / \ -- .. . +. . _/\ oo. | * . . . * / ;M\_ . ..oo. . .. . /\. / :IMM\ ....oo. Jerrad Pierce /\ / \ / ;IIWMM ..oo... 209 North Street +/ \ / \ . / ;WM ...o... Randolph, MA 02368/ \ \ ___/ :;IWM oooo.../\\ / :: ;;IIIMI .ooo.http://www.pthbb.org /\ \ : :::;IIIM ..ooo __ || || ::.:: MOTD on Sat Aug 19 2000 12 23: "Dear Lord, give me chastity and self-restraint... but not yet, O Lord, not yet!" -Saint Auguistine A.D. 354-430
Re: Maximum length input line
"PS" == Peter Scott [EMAIL PROTECTED] writes: PS No, the point is not that I want truncated lines but that I want to say PS "toss/leave back the excess over 100,000 characters when I do a INPUT, PS for I am sure that a line longer than that would be an error of some PS kind." Yes, Perl can handle many more characters than that before it PS starts to have problems, but so what. Maybe I have scripts where I would PS set it to 1_000_000_000 but that would still make sense. i will add this to the aio (advanced I/O) rfc. i have to get back to writing that set. someone kick me to do it. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
