Re: Help with Exceptions!

[gauthier@unilim.fr (Michel Gauthier)]

In article <DrEB77.Kwu@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:

>>  In article <gauthier-1405960958270001@164.81.60.62>,
>>  Michel Gauthier <gauthier@unilim.fr> wrote:
>>  >...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.
>>  
>>  This makes good sense for labels/goto's, but I don't think it is
>>  reasonable for exception handlers.  The whole point of exception
>>  handling is that the code detecting the error, and the code handling the
>>  error are separated from each other, and need not know about each other.

May I insist ?

From an assertion/proof point of view, sequential flow is really straightforward
(although in reverse direction...), conditional statements are simple (wichever
the number of branches), and "while" or "for" loops are manageable via the
preliminary design of invariants. This relates to the old "structured"
programming, which was assessed to be correct but insufficient.

For languages younger than Pascal, for "modular" or "object" programming,
hence for Ada (both -83 and -95), other features require understanding their
actual status according to assertions and proofs. The concern is for
program returns, loop exits, exception raises (widely used features) and
gotos, if any. 

Until now, I guess we can agree.

What I add is that there is nothing difficult in returning, exiting, raising or
going to. The programmer knows the assertion at the place of this
statement. Moreover, the statement is likely to be inside a conditional,
and there is a rich information, obtained as a logical conjunct, attached 
to this location of the program.
     What is difficult is bringing program flows together. This is always a 
disjunct, and the information is weakened, except for only one flow
(example : GETting and handling Data_Error). It is therefore really difficult
to manage multiple arrivals, and the point to be considereed with great
attention is the convergence point : the end of the subprogram, the
statement following the loop, the exception handler, the label.
    In many cases, there is only one arrival, and mastering the case is simple.
The maximum price to be paid is adding an assertion.
    When there are many arrivals on to the location, you CANNOT decide
what to do if you do not know the state of the program. How can you
build this knowledge if you have not establish the complete list of all 
arrivals prior to any other task ?

If you wish more detailed complements about these (heretic ?) ideas,
they have already been discussed in my book "Ada, a professional course"
(Macmillan, 1993) and in a dissertation (unfortunately in French) that
you can anonymously ftp from "ftp.unilim.fr" in the directory
/pub/labo_informatique/genie_logiciel/  (files hab_mg_*, essentially
part 2). These files are zipped postscript documents.

Obviously, you may also consider the assertion/proof point of view to be
a useless academic fashion. In this case, the above comments are of strictly
no interest for you. IMHO, it is a valid professional tool.

----------          ----------          ----------          ---------- 
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
----------          ----------          ----------          ----------