Re: Writing bulletproof code

From: E. Robert Tisdale (E.Robert.Tisdale_at_jpl.nasa.gov)
Date: 12/31/03 

Date: Wed, 31 Dec 2003 13:02:06 -0800

The Directive wrote:

> How do you make your code bulletproof? For example, I make my function
> bulletproof by validating every argument passed to the function. I
> ensure the arguments are within the expected ranges. This causes
> multiple validation at different levels and so there's a slight
> decrease in performance (since these checks ship with release code). I
> could turn off these checks (asserts) for release code but it would
> not protect the code from unexpected conditions since it's impossible
> to test every possible condition. My professor says that this is bad
> design. He says I should design according to specs and not include so
> much validation. What do you think? How do you make your code solid?
> How do you test your code and ensure quality?
> Any advice or ideas are appreciated.

First, you should design your code
so that the compiler can detect the most common errors.

1. Don't improvise with existing types.
    Define new types that have exactly the properties
    that are required and cause the compiler to issue
    diagnostic messages if you attempt to abuse them.

2. Distinguish between programming errors (bugs) and exceptions.
    Exceptions are expected but unpredictable [random] events
    that cannot be prevented and must be "handled" at run time.
    Programming errors are unexpected but predictable events
    which can only be prevented by the programmer fixing the bug
    after it is detected. You can use the assert C preprocessor macro
    to help you detect and locate bugs.
    You should try to handle exceptions
    at the point where they are first detected.
    If you can't handle the exception completely
    at the point where it is first detected,
    you *must* return or throw and exception object which contains
    all of the information required to handle the exception.
    You cannot use a function which returns an exception
    in an expression. You must throw (and subsequently catch)
    the exception instead.

Relevant Pages

  • Re: Exception handling
    ... Programming errors (bugs) are *not* exceptions. ... Bugs cause *unexpected* but predicable events once detected ... an exception should be "handled" ...
    (comp.lang.cpp)
  • Re: default namespace / Xmlvalidatingreader
    ... You dont get an exception in the case of the second file, ... validation warning should be thrown. ... XmlReader readerToUse = validatingReader; ...
    (microsoft.public.dotnet.xml)
  • Re: XmlValidatingReader / Default Namespace
    ... You dont get an exception in the case of the second file, ... validation warning should be thrown. ... XmlReader readerToUse = validatingReader; ...
    (microsoft.public.dotnet.xml)
  • Re: Exceptions as return values
    ... The OP stated he derived his exception ... exception type, such as ArgumentException, rather then ApplicationException ... I like exposing the exception as a property of the validation class; ... derives from the base Exception class. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Frame-based exception handling problem on Server 2008
    ... appcompt shims to skip exception handlers validation for binaries ... the safe exception handler table has nothing to do with C++. ... Server, as well as on earlier Server versions, so it shouldn't have ...
    (microsoft.public.win32.programmer.kernel)