Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!vsi1!altnet!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.misc
Subject: Re: compiler generated run time checking
Message-ID: <3998@enea.se>
Date: 15 Oct 88 19:16:09 GMT
Organization: ENEA DATA AB, Sweden
Lines: 35

Nevin J Liber (nevin1@ihlpb.UUCP) writes:
>Also, most non-trivial programs have to have run time checks explicitly
>coded, anyway.  And only through the explicit ones can the programmer
>do any kind of graceful handling.

If the programmer handles the check himself, we find here another
source of error. If we are really unlucky the check may be wrong. 
Legal index may be in the range a..b inclusive, but by mistake
he writes "IF a <= i < b THEN" and during test we never get to
the upper index.
  So leave the mechancial work of checking to the compiler. And
it is easier to turn off the checks in the compiler than the 
hand-coded ones. Also, we get a cleaner code.
  As for graceful handling, what you want is some kind exception 
handler you can trap to. With no checks at all you just hurry on
as nothing has happened, which is really dangerous.
  
Programmer-supplied checks can be a good idea if the language supports
a good way of expressing them without cluttering the code. C has
assert which could be of some help. They are rather a complement 
to compiler-generated checks, though.
  Eiffel is quite interesting here. My studies of the langauge
are not complete yet, but as far I understand there are very
few errors that the compiler can generate checks for. I can't 
think of anything else than void references. On the other hand 
Eiffel supplies several devices for expressing permitted conditions.
Most noticeable are the class invariants and the require/ensure
clauses that are part of the routine interface. And when you
build your system you tell can which classes that should have their
checks on and which shouldn't.
require/ensure clause are part of the routine interface. And you t
-- 
Erland Sommarskog            
ENEA Data, Stockholm         
sommar@enea.UUCP