Re: Help with Exceptions!

[gauthier@unilim.fr (Michel Gauthier)]

In article <EACHUS.96May13172506@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>>  In article <319764DA.3A8C@io.com> Dave Jones <davedave@io.com> writes:
>>  
>>    > Most others seem to have an experience similar to mine: "goto"
>>    > means you need to change your approach.  So I was wondering, has
>>    > anyone out there ever encountered a situation where "goto" was
>>    > actually necessary?
>>  
>>     The only two cases in which I have used gotos in are:
>>  
>>     1) Testing the compiler's implementation of gotos for correctness.
>>  
>>     2) Implementation of table driven finite-state machines.

In the mainlines, I agree. When the design (before any language implementation)
is a finite-state machine, a direct implementation of this design can be more
sensible than any workaround suitable only to fit a priori style rules.

Three useful comments :

 - implementing a finite-state machine with gotos requires accurate
documentation of the initial design,
 - blocks are a worthwhile feature to compile-check some bad uses,
and local variables are also a valid choice :
     <<State_1>> declare ... end ;
     <<State_2 >> declare ... end ;
     ...
 - a rule may not be applied if it is cheaper to convince the project
technical manager than to apply the rule.

>>      Now those of you with academic backgrounds will cleverly realize
>>  that this can be "fixed" with a recursive call. Those with compiler
>>  experience will understand that I have seen parsers in states with
>>  several hundred (often large) frames on the stack.  Doubling the
>>  number of stack frames for stylistic reasons is very unappealing.

It is difficult enough to teach recursivity, please do not add useless
complexity. I agree with your conclusion.

>>       Are there any other known cases where a goto "makes sense" in
>>  Ada?  The only one I can come up with is for teaching gotos!

The only two uses of gotos I have ever written in "structured" languages are :
 - implementing a report in a lexical parser in Pascal (a raise of later
languages),
 - coding the read of a date using reading a year, a month and a day. Every
internal read has four exits : read the next item (exit the current loop),
retry the current item (a normal loop), cancel the whole operation (raise)
and retry the whole operation (how to do without a goto or great complexity?).
But... this looks really like a finite-state machine.

ADVICE :
A good way to assess the use of gotos (and in fact of any kind of reports,
exceptions or any other), is to identify that the complexity arises from the
convergence of program flows. Exactly like loops require invariants, gotos,
program returns and report handling require an invariant, too (this is why 
Eiffel "retry" works well). Unfortunately, loop start has exactly two possible 
origins, whereas gotos and report handlers can have much more (especially 
for predefined exceptions) and that they are too often implicit. So, I
teach the 
rule : for a label, a program end or an exception handler, always establish a 
complete list of all gotos or raises and attach the corresponding assertion.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------