Peter Scott wrote:
> Technically, the only ones of these that impact the core are: message, and
> link. The others might be better broken out into another RFC. One RFC for
> throwing and handling exceptions; another one for what goes in the exceptions.
So that was one thing I tried to do in RFC 119: it discusses only throwing and
handling exceptions. It leaves open what is thrown. It allows for simple
exceptions in simple programs to use simple mechanisms (throw a scalar); it allows
for complex but non-OO exceptions to be thrown as a list; it allows for complex
OO-type (C++/Java-type) exceptions to be thrown as an object reference.
I think many of the ideas expressed in RFC 88 regarding the useful contents of
what data should be thrown as part of an exception are excellant, and didn't want
to repeat them in RFC 119. They deserve an RFC of their own. Preferably, IMHO,
divided down into unit operations: for example, the specification that stack
context information should be displayed or included in the data thrown is an
excellant idea for large programs. Such an RFC should specify the types of
details needed, and hopefully a simple way of obtaining each type and passing them
on to throw (maybe as simple as "throw ... '-callstack', [ caller 100 ] ...;", and
for OO throws, that could be done as part of the construction of the object to
throw).
RFC 119 also addresses one feature not found in any of the OO exception mechanism
RFCs, including the "unified" one which has ignored RFC 119 so far: bundling the
"cleanup" code with the "setup" code. I find the syntax proposed there an
extremely handy way of dealing with cleanup code.
$fh = open ( ... ) except close ( $fh );
is an extremely concise way of expressing the cleanup code corresponding with the
setup code at the point in which the mental context is focused on the need to open
the file. In version 2 of RFC 119, I will be adding a variation to this: the
finally keyword can be used in place of except to indicate code that should be
executed not only if an exception is thrown by but also when the scope exits
normally. Hence, at the point at which you open a local file in a routine, you
can specify its closure via:
$fh = open ( ... ) finally close ( $fh );
This will handle the close of the function regardless of how the scope exits: via
a return, via falling out the end, or via an exception.
Today I often find myself coding in the following manner:
open HANDLE, ... || die ...;
while ( <HANDLE> ) {
}
close ( HANDLE );
and then going back up and filling in the block. This way I don't forget to close
the HANDLE at the appropriate time, and as long as I don't return from within the
while, all is well.
OO people could think of the above "finally" clause this way: the left hand side
is a "mini-constructor" and the right hand side is a "mini-destructor" for the
left hand side. The "methods" are the code executed within the scope.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
