Re: (part 30) Han from China answers your C questions

Andrey Tarasevich said:

Richard Heathfield wrote:

You present two possibilities: code that doesn't crash and doesn't work
(i.e. silently produces incorrect results), and code that crashes. You
go on to suggest...

Incorrect. I did not present anything. Whatever I said applied to the
two possibilities presented by other posters before me.

I read it differently, but okay, it's probably not worth arguing over.

<snip>

A program that crashes tells me nothing sufficiently useful to help me
fix the problem. "It's screwed" is insufficiently useful, except insofar
as it persuades me to ditch the program and try something better.

Actually, when I said "crashes" I actually meant "aborts as soon as
possible", which includes a genuine crash as the worst way to abort or a
more graceful abort with a custom error message. But all these variants
fall into your "It's screwed" category anyway, so that should make much
difference.

Well, no they don't, and it does make a difference. A useful error message
may enable me to track down the problem and fix it. A non-useful error
message will not. For example, "file not found" is (marginally) useful,
although it's a little coy. "/home/me/here/foo.txt not found" is rather
more useful. My "It's screwed" category was intended to convey that a
crash carries an implicit error message of its own, i.e. "my programmer
got it wrong". If that's not the message we want our users to get, then we
should do our best to prevent our programs from crashing.

In any case, a program cannot tell anyone anything useful at all when it
runs into genuinely unforeseen problem, which is what is being discussed.

On the contrary, we're discussing a problem that has been foreseen.
Assertions can and should be used to check program assumptions during
development and early testing.

A program that silently but predictably produces incorrect results can
be studied and fixed.

Firstly, "predictably" is quite a requirement here. It might be simply
impossible to detect the incorrectness of results in situations when the
"golden" result does not exist (as that's virtually always the case
outside of the regression QA environment). On top of that, it is rather
strange to expect any form of predictability from the incorrect result.

A sorting program that arbitrarily crashes is difficult to diagnose. A
sorting program that always produces its results in descending order
instead of ascending order is easy to diagnose. A calculator program that
arbitrarily crashes is difficult to diagnose. A calculator program that
always adds six-digit values incorrectly is easy to diagnose. An email
client that arbitrarily crashes is difficult to diagnose. An email client
that always fails to delete emails from the server is easy to diagnose.

Incorrect results are always predictable, provided the program doesn't
exhibit undefined behaviour. Given a well-behaved (even if incorrect)
program, the same set of inputs - admittedly for a very wide definition of
"inputs" - will always give you the same set of outputs.

Secondly, this is very application-area specific, but no, in general
case a faulty program working in the production environment cannot be
possibly allowed to run for the purpose of "studying and fixing". It is
exactly the case when "better safe than sorry" principle should be
applied.

What makes you think crashing is "safe" is beyond me.

Best of all is a program that, having determined that something is
wrong, produces noisy error messages, and then fails gracefully (perhaps
halting, but certainly not crashing).

You seem to be contradicting yourself here. Isn't a halt just a form of
"It's screwed" result, which you just criticized several sentences above?

No, certainly not. There's a vast difference between halting and crashing.
And what would you rather see, as a user - or even as a programmer? This:
"Program error $2AE4:10F2:223B:FF08 [Lose your work] [Send pointless
report that will be ignored, and *then* lose your work]" or this: "File
not found: /home/me/here/foo.cfg - without this configuration file, the
program can't find important information that it needs for processing your
work further. See http://mumbleco.url.ok/products/foo/bar/config.php for
further information on configuration files. Your work has been saved in an
emergency file, /home/me/here/01384921.tmp - fix the configuration file
problem and then restart the program using the -R switch and specifying
the above emergency filename, e.g. foo -R /home/me/here/01384921.tmp"

Anyone who thinks a crashing program is a good program doesn't belong in
the industry.

Hm... True, but irrelevant. In situation when program runs into a
unforseen error any form of the graceful exit is out of question, and
there only two possibilities: a crash or a continued execution in
invalidated state. The crash is a better alternative in a case like
that. Anyone, who doesn't understand that doesn't belong in the industry.

I have to disagree with this. If the error is truly unforeseen, you don't
get a choice about what to do, because if you did have the choice, you
foresaw the error. If at that point you chose to allow the program to
crash, you were being lazy.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.

Relevant Pages

  • Re: (part 33) Han from China answers your C questions
    ... If it crashes I know for certain it has failed and can start ... concentrating on testing with the specific input that caused the crash ... The same applies to incorrect results. ... one aspect of undefined behaviour. ...
    (comp.lang.c)
  • Re: (part 33) Han from China answers your C questions
    ... positive delta) then you can can more information from the crash since ... The same applies to incorrect results. ... But I'd rather debug incorrect results any day. ... although repeatable crashes can be easy to debug. ...
    (comp.lang.c)
  • Re: (part 30) Han from China answers your C questions
    ... (i.e. silently produces incorrect results), and code that crashes. ... which includes a genuine crash as the worst way to abort or a more graceful abort with a custom error message. ... In situation when program runs into a unforseen error any form of the graceful exit is out of question, and there only two possibilities: a crash or a continued execution in invalidated state. ...
    (comp.lang.c)
  • Need Help: LibXML + LWP::Simple Is Making Perl Crash
    ... No error message. ... crashes. ... WinXP comp with ActivePerl 5.8.8 -- will crash reliably. ... # other weirdness with getting text from XML nodes, ...
    (comp.lang.perl.misc)
  • Re: Problem painting the control
    ... The error message is sometimes unhandled exception stack and sometimes ... When I single step it doesn't crash at the position I ... mentioned,but when I let the application run it crashes and the stack ...
    (microsoft.public.vc.language)