I'm replying to your first message because it contains more information,
but I'm also reading your second one in parallel while I respond.
Tony Olekshy wrote:
> Glenn Linderman wrote (in RFC 119 v2):
> >
> > RFC 119 wants to make available to the catch block exactly the
> > same list of parameters supplied to throw. This is prevented
> > by RFC 88's stringification and concatenation of parameters.
>
> Not quite true. You can't get exactly the same list, but you can
> get exactly the same list plus some more ;-)
>
> try {
> throw Exception "Can't foo.", params => \@params;
> }
> catch {
> print "Params: ", join(", ", @{$@->{params}}), "\n";
> }
OK, I agree there are apparently ways that weren't obvious to me in
reading RFC 88 to pass as large a list of parameters as desired from
throw to catch using RFC 88. However, the RFC 119 syntax for that is
simpler on both ends. You've currently forced yourself into that by
making throw a method of Exception, which also causes the "must have a
parameter" problem you've been discussing with other posters. With
them, you've admitted throw could be just a function. I claim it could
also be a perl keyword, and I'm sure you'd agree, but are just trying to
avoid needing that. I'm sympathetic to avoiding keywords, but I'm
willing to leave that up to the implementors.
In my RFC 88 vs 119 comparison, I point out a way that RFC 88's
Exception object could be a way of implementing RFC 119's syntax.
Instead of the above syntax, RFC 119 wants a simpler syntax:
throw "Can't foo.", @params;
and on the catch side a predefined list or array of the parameters that
were thrown. RFC 119 presently suggests using @_ for that, but I'd be
happy to be able to access them via some other name, as long as it was
short. Maybe @! is available? I'll stick with @_ for the
moment...resulting in
catch { print "Params: ", join (", ", @_), "\n"; }
> > RFC 119 makes those parameters available to the catch block
> > via @_, whereas RFC 88 doesn't presently make the
> > parameters available.
>
> RFC 88 makes the *exception* available via $@, and the params can
> be kept in the exception, as illustrated above.
So I'm not averse to having the exception variable in $@, and the
exception stack in @@ (although I think @@ is a really confusing name,
given that @ means array when it isn't the name of one, but $@ is also
confusing for the same reason. I guess it works, though). I guess the
additional piece I'm asking for is an easy way for catch to reference
the thrown parameters without a bunch of OO dereferencing syntax. $@
and @@ are great background tools, and have great characteristics to
assist in debugging, but using them shouldn't generally be necessary to
handle simple exceptions, so let's make it easy to handle simple ones,
by providing a simple list of parameters to catch. Via @_, or @!, or
@something_shorter_than_this or @{$@->params}.
> > RFC 88 uses the finally keyword as a subclause introducer for
> > the try statement. RFC 119 uses the except and always keywords
> > as subclause introducers for any statement.
>
> RFC 88 uses finally *and* catch (just like always and except).
>
> > RFC 119's except clause is executed only if an exception occurs,
> > which exits the scope containing the statement in which it is
> > defined.
>
> Same as 88's catch clause.
Close, but not quite. While you later recognized this, you didn't make
it clear whether you understood that RFC 119's except clause can be used
to factor common "catch" code out of large terminal catch phrases... for
the case where you have multiple specific exceptions you want to catch,
and some separate action for each of them, but then lots of common
cleanup code for each of them.
> > RFC 88's finally clause is executed if an exception occurs, or if
> > flow of control falls out of the bottom of the try statement.
>
> Same as 119's always clause, I believe.
Same theory, but RFC 119's always clause is augmented so that it also
gets executed if the scope is exited via any branching statement within
the protected (implicit "try") block. Note that I also am unsure about
whether it is possible or not to branch out of a catch block, but that
is not what I'm saying for the always clause... I'm saying that always
gets executed when the scope is exited by goto (or next, etc.) or return
from the normal flow of control. In other words, always can be a useful
construct even in a program that doesn't use exception handling in any
other way... it isn't tied to a catch block in any dependent way. But
throw is one way scopes can exit, so there is a relationship if
exceptions are used.
> > It is not clear whether the finally clause is executed if the
> > try statement is exited via a goto or return, but the statement
> > is made that once a try statement is entered, it is guaranteed
> > that the finally clause is entered, but none of the
> > discussion mentions exiting via goto or return.
>
> Quote from RFC 88 + ISSUES + Mixed Flow Control:
Yes, I saw that mixed flow control statement in RFC 88. But you do not
explain what happens regarding the finally clause in this situation, if
the branch is taken.
my $p; try { $p = new P; goto exitpoint if ...; } finally {
$p->Done; }
exitpoint:
Does the finally clause execute or not? In RFC 119, the always clause
below would get executed, whether the branch is taken or not.
my $p { $p = new P always $p->Done; goto exitpoint ...; }
exitpoint:
So this is an issue of unclarity of RFC 88, which you can no doubt
easily resolve.
> > RFC 119's always clause is executed if an exception occurs, or if
> > flow of control exits the scope in any other manner.
>
> Same as 88's finally clause.
Maybe, depending on the above.
> RFC 88 proposes that finally is entered even after return in try.
I don't think this was explicitly stated.
> RFC 88 acknowledges that this may not be possible, as quoted above.
The above quote dealt with branches out of the catch clause, not
branches out of the try block.
> RFC 88 and RFC 119 will either both be able to do it, or neither.
> This would be obvious if RFC 119 used a try keyword, instead of
> pretending to a "normal" local-flow-control block.
I agree that RFC 88 and RFC 119 would suffer similar consequences
regarding branches out of catch, finally, and always blocks. If
branches out of catch, finally, and always blocks cannot be achieved, it
would be nice if they were forbidden at compile time. In both
proposals, it is obvious what code is within the blocks.
> > RFC 88 has nothing that directly corresponds to RFC 119's
> > except clause, although that logic could be included at the end
> > of each catch clause.
>
> No, you've completely mis-read RFC 88 here. Its "catch" clause
> directly corresponds to 119's except clause, although I believe
> catch is a bit more general purpose as proposed.
You already figured out the error in the above statement. I already
said some more about except above.
> I completely agree with what 119's "always" does, and how nice and
> concise the syntax is. I just think that should be a separate RFC,
> that "always" should be invoked whenever the lexical variable it is
> associated with goes out of scope (whether or not by unwind), and
> that really, exception handling doesn't enter into it. It's just
> a lexical destructor block.
I suppose always could be a separate RFC, orthogonal to RFC 119 or 88,
to add to either. On the other hand, maybe RFC 88 wouldn't need its
finally syntax at all if a separate always RFC made prime time.
Although maybe you'd need it for compatibility.
> > I believe that any needed exception handling logic can be
> > expressed at least as concisely and clearly using RFC 119 than
> > using RFC 88.
>
> In order to convince me of this, you'll have to present a clear
> set of examples of how RFC 119 handles the kinds of things shown
> in the EXAMPLES section of RFC 88 (and, without all that C stuff).
I'll try my hand at this in a separate response, bit later.
> > I'd like to see two modes of operation by the exception class:
> > "normal" and "debug", where normal omitted many of the
> > implicit features (preserving the call stack, debug info, object
> > info, etc.), but could be turned on easily across all loaded
> > modules via some command line switch.
>
> RFC 88 acknowledges that the stack tracebacks may not always be
> wanted, so only the "debug" attribute is really affected. To quote:
I knew it did...
> snapshot
>
> Used internally to generate the "trace" instance variable.
> Designed to be overridden in derived classes for performance or
> extension purposes. See the description of the trace instance
> variable, above.
But overriding it in the class isn't sufficiently easily made a dynamic
choice at runtime. Really this is the sort of thing that needs to be
globally on/off. Unless some inner module has a specific need to ensure
that it is on, because it has code that uses the data, rather than just
doing default error reporting of uncaught exceptions, or doing specific
reporting of unexpected exceptions. So I guess I'd like to see it off
by default (for performance), able to be turned on with a command line
switch (for convenience in debugging), and able to be "pushed and set"
by modules that really need the data for some functional purpose. Note
that "pushed and reset" wouldn't be a legal operation, because that
would undo the effect of the command line switch.
> It might be a good idea if the default snapshot method took a
> dynamically scoped state variable into account, and maybe we could
> just add it to a top-level try using the following syntax (already
> proposed for other things in RFC 88):
Would that achieve the goals I stated above? I'm not sure what the
syntax below means... "debug" doesn't look like a variable.
> try debug => 0, {
>
> # no snapshots anywhere "under" here in call stack.
> }
>
> It probably would be a good idea if you clean up some of these
> misconceptions in your next release of 119, just so people don't
> get the wrong idea about 88 ;-) Thanks.
I'm happy to clear up any misconceptions in RFC 119, and also to attempt
to clarify any obscure points in RFC 119, that made you re-read it
multiple times to get it. After reading both your messages, however,
I'm not clear on which points you still consider misconceptions. If,
after reading this message, you could suffer with me long enough to
re-read RFC 119 again, for the purpose of composing a message of
specific places where it could be clarified, and where it contains
errors of fact regarding RFC 88, I'd be glad to work from that message
to improve RFC 119.
> Yours, &c, Tony Olekshy
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
