[Boulder.pm] Academic vs Production Code

[Walter Pienciak]

On Thu, Aug 23, 2012 at 03:29:16PM -0600, Rob Nagler wrote:
> 
> Here's a discussion about Fast Fail (or vice-versa :)
> 
> http://en.wikipedia.org/wiki/Fail-fast
> 
> Code always makes assumptions, and these need to be checked in
> appropriate (not all) interfaces.  The example was opening a file,
> which can fail, and if it does, the program has to stop doing
> something it should be doing.  Most of the bugs in software are
> related to mismatched assumptions.  In this case, the operating system
> and language processor assume opens can fail and need to be checked,
> but the program is assuming it won't and doesn't check.  Another
> approach, which is Pascal-like, is that the language processor fails
> for the program.  This is the nanny-state solution, and it doesn't
> work either.  You don't want the program to fail when you can't open a
> file in an editor; you want it to produce an error message, and ask
> the user to correct the file name.

I just want to say, Rob, that we support your position:

    "There are significant economic benefits in the early
    detection of faults. This implies that test set development
    should start as soon as practical following availability of
    the unit requirements documentation because of the resulting
    requirements verification and validation. It also implies
    that as much as practical should be tested at the unit
    level."

    Appendix B item B2.4
    IEEE Standard for Software Unit Testing (IEEE Std 1008-1987)

;^)

Walter