Re: Logic Errors and Ada (Was: A big hairy thread on Ada, Quality, and Drivers)

[softeng3456@netscape.net (soft-eng)]

mcq95@earthlink.net (Marc A. Criley) wrote in message news:<254c16a.0305160930.40bb42f9@posting.google.com>...

> Assuming an Ada-coded system where proper usage has been made of
> strong typing...
> 
> I'm not positive what you mean by "type errors"--I see two potential
> interpretations that are relevant to Ada:
> 
> 1) Type conflicts
> 2) Range errors
> 
> The first, type conflicts, are fixed almost without thought by an Ada
> programmer, since the program won't compile until they're are. If I
> swap Lat and Lon in a procedure call, or mis-assign a "Plan_Number"
> value to an "Engagement_Number" variable, it's immediately caught and
> I fix it--I don't even bother to count that as a defect--so it never
> makes it onto a bug list--that's just a momentary "oops" on my part.
> 
> What happens when you swap nLat and nLong in a function call? You get
> an object file, I get a compile error.
> 
> When does it get noticed? When you run a test, when I look at the
> compiler's output.
> 
> These little type conflicts are always caught and fixed, without  the
> Ada programmer even thinking about it--these errors just never make it
> into the test regime, because they've been long since dealt with.
> 
> Range errors get automatically detected at run-time in an Ada-coded
> system, where they can be as simple as an off-by-1 error, and who
> hasn't dealt with that one?
> 
> What happens when your indexing is off by one? The program may crash,
> or it may not. It may corrupt neighboring data, or it may not. It may
> often exhibit erratic behavior, or it may do so intermittently.
> 
> When my indexing is off by one an exception is raised and I
> immediately know there's a problem that I need to identify and fix.
> 
> ------------------------------
> 
> But granting this low estimation of "type error" occurrence, that
> means many of the remaining errors would be designated as "logic
> errors", and it's been suggested that this is the type of the majority
> of errors (which I believe is true), and that neither Ada nor any
> other language is inherently capable of preventing logic errors--also
> true.
> 
> So your assertion appears to be that 1) most software errors are logic
> errors, and 2) Ada's strong typing only helps prevent an uncommon type
> of error (type errors), therefore the effort required to work with or
> around Ada's strong typing adds no value to the detection and
> correction of the predominant type of error (logic).
> 
> Okay then, so how _does_ one know they've got a logic error in their
> code?
> 
> The error is going to manifest itself in one of three ways:
> 1) The program runs but the functionality isn't as desired. This may
> be obvious (it immediately exits), or not (a cumulative microsecond
> drift that becomes noticeable only after a couple days caused by a
> counter not getting reset).
> 2) The program crashes at some point.
> 3) The program runs but behaves erratically, and this behavior may be
> intermittent.
> 
> In the third case, clearly Ada and strong typing would likely be of
> benefit here, since such erratic behavior may arise from "type errant"
> run-time behavior that was initiated by executing the wrong logic.
> Pretty much every time an unexpected exception occurs in an Ada-coded
> program, the cause is a logic error that causes the execution of code
> that is an inconsistent internal state (because that code wasn't
> supposed to be executed!). Stale data values may be referenced,
> garbage values may be in variables, and as soon as Ada does a range
> check on them, everything halts--and you can go track down the
> problem.
> 
> In the second case, one has to determine what led to the crash: Was it
> an immediate crash at the point of error? E.g., trying to write
> through a null pointer? Or was the program getting messed up
> internally, but gave no indication and continued to run for awhile
> before the cascade of errors got so bad that it crashed? If the
> former, Ada's no better or worse than any other language in which that
> occurs, but if the latter, you've just got case #3 again, but where it
> does eventually terminate.
> 
> In the first case, things like peer reviews and formal inspections
> have proven to be of measurable assistance.
> 
> > So the tradeoff is, possibly a bug or two caught
> > at compile time rather than during testing, versus
> > using a very large language that was created by fiat.
> 
> Again, you're not counting the errors that _never_ occur _because_ of
> strong typing. (And you've also been ignoring all mention of how the
> type information embedded within Ada software due to its strong type
> model also aids correctness and maintainability.) Because C/C++
> doesn't flag type conflicts among values having the same base type
> (int or float) and also does implicit type coercion, you never see
> such conflicts when you're compiling your software, and by the time
> they manifest themselves--in test--they've become logic errors: "I
> meant to use Latitude rather than Longitude here."

That sounds to me an unrealistic level of discipline: subtyping
to the extent that all lattitudes and longitudes (and things
along that line) are separate types.  More common usage is that both
will be just real numbers (floats), whatever the language chosen.  So
academically this is an advantage, in practice it won't be there.
(Similarly, as other messages point out, in practice, any usage of
subranges you will see in Ada is just what you have in C++,
int8, int16, int32.  Though in a classroom setting it may sound like
a great advantage to be able to have my own subranges of integers
from 1 to 9102 each and every time I need it...)

But in any case, you sure can create Lattitude and Longitude classes
in C++ as well if you are so disciplined, so the advantage you are
pointing out is not very clear.