From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3afc1f4defb71eb39b20882e5243fb22@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] same functions everywhere
From: rog@vitanuova.com
In-Reply-To: <1052497182.736.14.camel@pc118>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon, 12 May 2003 18:22:01 +0100
Topicbox-Message-UUID: a99fea0c-eacb-11e9-9e20-41e7f4b1d025

> I agree with those here that hold the opinion that exceptions are no
> substitute for a well-thought-out and well-notated program (we used to
> call it "structured programming"). Need error handling obscure the
> "all's well" logic of the program?

leaving safety-critical systems aside (where every error *must* be
handled appropriately), there are runtime errors that can occur with
very low probability which mean that the program is unable to proceed.

in many programs, the only reasonable thing to do in such a case is to
exit.  in some others, there might be other actions that are worth
performing (e.g.  an editor might save current work; a multi-threaded
program might kill the other threads, etc).

if i wish to enable such a thing without any sort of exceptions, there
must be a return path back from *any* function that calls (directly or
indirectly) any other function that can incur one of these errors.

i.e.  it is never acceptable to write a function f returning type T
without also providing an additional error return (which must then be
propagated up the stack).

the additional error return, and the code necessary to check and
propagate the error, certainly seems like clutter to me, since i would
otherwise choose not to handle the error (or activate some
"fingers-crossed" recovery mechanism).  the exception mechanism also
enables me to catch errors generated by the run-time-system, where
there's no obvious place to handle the error (e.g.  stack overflow,
division by zero).

note that it's only clutter *because* i would have chosen not to try
to handle the error.  thus i would not count the error checking code
around fopen as clutter, because i will almost always choose to handle
that error appropriately (e.g.  by printing a sensible error message).

safety-critical systems are very different in this respect.  perhaps
in this kind of system, every division operation *should* have a check
for division by zero around it...

  cheers,
    rog.