John Porter wrote:
>
> Tony Olekshy wrote:
> >
> > I think "always" should be part of an explicit statement, such
> > as "try", not some implied property of block structure introduced
> > by a dangling clause.
>
> Why?
There's an old engineering joke about instructions that go on and on
for pages about how to attach the cover with the special bolts and
torque them just so and get how to do the x-ray tests and sign off
the job, and somewhere near the end there's a note that says, "before
attaching the cover be sure to test the humdinger transpondence."
Which of the following sets of instructions is better? These:
1. Skip step one.
2. Kill yourself.
3. Note: if step one was skipped then skip step two.
Or these:
1. Warning: if step two is skipped then skip step three.
2. Skip step two.
3. Kill yourself.
When instructions are written which modify the way other instructions
are to be carried out, the modifying instructions should appear before
the modified instructions. For humans reading source code that's
"before" in source code order, for CPUs it's in instruction sequence
order.
That's what "eval" and "try" do. They tell you up front, "Warning,
if the following block unwinds, do not propagate your mind out of here
as you would normally, instead examine the source code following this
block, because trapping is now in effect for the scope of the block."
Trapping is special; it's not like traditional flow control because
it does not involve any in-flow visible source code signal which
indicates to the reader that the implied goto-on-unwind is in effect,
unless we explicitly require something like eval or try. It's not
like a dangling continue block, because such blocks are triggered by
an in-flow visible statement like next. That's why [RFC88] quotes
[ESE-1994] to the effect that, "Among the features offered by
programming languages to support exception handling are (1) The
ability to distinguish the normal control flow from the exception
handling flow to make the structure of the program clear [...] Most
early programming languages do not provide specific features for
exception handling, but rather use the normal constructs to implement
it. [...] Obviously this and other ad hoc methods do not satisfy the
requirements listed above."
On the other hand, a post-hoc "always" says, "Note: if you've already
propagated your mind out of here, and you aren't reading this code,
you shouldn't have." It's like a roadway sign that says, "The section
of road you have just finished driving on may have been slippery if it
was wet." It's correct. It's do-able. It's a poor way to do it.
Yours, &c, Tony Olekshy
ESE-1994: The Encyclopedia of Software Engineering, J.J. Marciniak
(editor), John Wiley & Sons Inc, 1994. ISBN 0-471-54002-1
RFC 88: Omnibus Structured Exception/Error Handling Mechanism,
http://www.avrasoft.com/perl6/rfc88.htm
