Re: Why leave the error handling to the caller?

Johan Bengtsson said:

Richard Heathfield wrote:

<snip>

And thus we have a recovery strategy which achieves the correct
program output even in the face of a malloc failure. And that's why
library routines shouldn't bomb out.

QED.


Ummm, am I missing something here?

No.

I do agree that the library functions should not make the decision and
kill the program, and (depending on the program) returning NULL from
makestrings would be the the best behaivour.

That's the whole thing. So you're not missing anything.

I do however not really agree to this solution of error handling. If
the intended behavior of the program is to simply output all the
strings with no further processing there would never be any reason for
storing them (and thereby not having any trouble to begin with) and
whatever is in the error recovery part of the program would better be
the *entire* program.

But consider that there might be a real benefit to be had from the
dynamic allocation solution which couldn't be got from the static
solution (e.g. raw speed, perhaps); nevertheless, the static solution
would be "good enough" (albeit slower, perhaps). The status bar might
read something like "want 38GB for WhizSort, failed to get 38GB, can't
do WhizSort, switching to TrudgeSort..."

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
.