There are cases when you want to leave the output of the program in
consistent state before you die (and you don't need extra memory to
achieve that consistency). Or even if the program cannot continue its
work, it would rather lurk around and wait for somebody to rescue it
instead of just dying. And in cases like that you just cannot use
libraries that call sysfatal.
Thanks,
Lucho
On Jun 9, 2006, at 4:55 PM, [EMAIL PROTECTED] wrote:
've written many production systems this way. i never once had a
malloc
failure that was not a result of a catastrophic bug or h/w failure.
except in the case where you know you might be requesting an
unreasonable
amount of memory, i have always thought that it makes more sense to
limit
the number of failure states by just quitting when malloc fails. i
want my
programs to be as deterministic as possible. i would much rather
have them
die than get into some untested failure state. (does any project
that tries
to recover from malloc failure actually test failure at each
recovery point?)
the current fad is c++ exceptions. the idea seems okay, but the
programs
i know that make use of c++ this way (mozilla comes to mind) do not
seem to be very stable or reliable.
- erik
On Fri Jun 9 17:53:03 CDT 2006, [EMAIL PROTECTED] wrote:
Another example is using emalloc in libraries. I agree that it is
much simpler to just give up when there is not enough memory (which
is also not very likely case), but is that how the code is supposed
to be written if you are not doing research?
Thanks,
Lucho
