From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!sei.cmu.edu!ae
From: ae@sei.cmu.edu (Arthur Evans)
Newsgroups: comp.lang.ada
Subject: Re: Pre-condition vs. Post-condition
Message-ID: <23141@as0c.sei.cmu.edu>
Date: 25 Mar 91 16:00:58 GMT
References: <20600091@inmet>
Organization: Carnegie-Mellon University (Software Engineering Institute), Pgh, PA
In-reply-to: stt@inmet.inmet.com's message of 24 Mar 91 21:23:00 GMT
cc: stt@inmet.inmet.com
List-Id: <comp.lang.ada>

Tucker Taft (stt@inmet.inmet.com) states that, in general, exceptions
should be used only for serious errors, and that it is rarely proper to
provide local handling.  I disagree,

In many cases, a programming is continually processing data, and (as
others have already remarked) it is almost as hard to determine in
advance if the data are flawed as it is to do the processing.  Examples:

  - An aplication is processing radar data.  The code might determine
    that a plane has moved 100 miles since the last report a few
    milliseconds ago, or changed altitude by 4000 feet, both impossible.
    Probably the problem is noise in the returned radar data, and the
    best way to deal with it is to raise a BAD_RADAR_DATA exception.
    The calling code can note the problem and ignore the data, if the
    problem is infrequent. It might report frequent errors in a trouble
    report.  In any case, though, the code processing the data can best
    serve the application by just saying (in effect), "These data are no
    good.  Do something about the problem."

  - Consider reading a text file in which each line contains formatted
    data.  The caller would check for EOF before calling the routine
    which reads the next line and processes it.  Again, invalid data
    might be reported by a BAD_DATA exception.  However, a bad input
    file might be manifested in the processing code by an unexpected EOF
    -- a line with missing trailing fields or a missing line-terminator.
    The data processing routine would probably find it most convenient
    to catch the EOF exception and reflect it to the caller as BAD_DATA.
    We have here a mixture of checking for the EOF by the caller, for
    whom it is an expected event, and catching an EOF exception in the
    line processor, for whom it represents incorrect data.

I think most dogmatic statements about how exceptions should be used
turn out to have so many exceptions as to be useless.  (Sorry about
that.)  Exceptions represent yet another tool in the hands of the
application designer; as with other tools, they must be used with care
and taste.

Art Evans