Flash Gordon said:
<snip>
Quote:
even proving that the result is a prime won't prove that it is the
correct output.
Okay, fair point. So how are you going to test it? You *were* going to test
it, right? And how would crashing solve your problem here?
<snip>
Quote:
Quote:
Quote:
>>In my experience if the crash is at time t and the incorrect results
>>(if a crash is prevented) can be spotted at time t+delta (for some
>>positive delta) then you can can more information from the crash since
>>it is nearer the actual bug.
>>
>It's just a symptom, not a cause.
>
So are the incorrect results.
Yes.
Quote:
Quote:
>And it's merely a fact. "We got this far,
>and it crashed." But you don't actually know why.
>
The same applies to incorrect results.
Incorrect results typically give you more information about what went wrong
than no results whatsoever. If your output is:
"MANCHESTER UNITED 0, LEEDS UNITE"
you've already got a pretty good idea of what went wrong, right there. Or
if it's "MANCHESTER UNITED 0, LEEDS UNITED -2147483648, that's a pretty
big clue, too. But if it's, then you have to start guessing.
Quote:
>
Quote:
>Yes, backtraces are very
>useful. I'm not saying you *can't* debug a segfault. And it's not even
>*that* difficult to do. But I'd rather debug incorrect results any day.
>
I would rather debug starting from as close to where the error is as
possible.
I would rather debug starting from as much relevant information about the
error as possible - including, but not limited to, its ostensible
locality.
Quote:
Quote:
>And I certainly wouldn't want my code to crash in production.
>
Same here.
Then what are we arguing about? :-)
Quote:
As a result on a legacy project I have slowly added in lots
of traps for "impossible" conditions.
Quotes noted with wry smile. Been there, done that, got the impossible
tee-shirt.
Quote:
Quote:
>I wish I
>could claim that my code never does crash in production. Of course,
>sometimes it does happen, but it's a circumstance that I would very much
>prefer to avoid.
>
I try to avoid it as well. I'm also not arguing that crashes are a good
thing, although repeatable crashes can be easy to debug.
Yes, "repeatable" being the important word here. I've found that keeping
the behaviour well-defined is a great aid to repeatability, and
well-defined behaviour means no crash - QED! :-)
Quote:
Quote:
Quote:
>>>What's more, I am
>>>left wondering what damage the program may have done in the way of
>>>filesystem corruption, dropped packets, etc during its route from
>>>undefined behaviour to crash.
>><snip>
>>>
>>There is the same problem if you get incorrect results.
>>
>No, sir, there isn't - if the behaviour of your program is
>*well-defined*, you know the limits of what it can do. If the behaviour
>of your program is undefined, all bets are off. And a crash is basically
>one aspect of undefined behaviour.
>
With a lot of SW the limits within well defined behaviour can include
completely trashing your data.
Yes, but only the relevant data! The data that you know to look at, because
it's within the domain of the program's activity. With undefined
behaviour, you have to check Keith Thompson's hard disk, in case your
program running on your machine messed it up. Okay, so that's a caricature
- but the underlying point is genuine.
Quote:
Quote:
Quote:
>>How do you know
>>it has not, for example, updated a million records in your database
>>with garbage values before the visibly incorrect result is seen?
>>
>If it's a well-defined program, I know it didn't do that because it's a
>graphics filter, not a database program. But if the behaviour were
>undefined, I couldn't be sure.
>
You introduced networking as a possibility, I introduced databases.
Sure, but my point is that IF the behaviour is well-defined, you only have
to look in the relevant places. If the behaviour is undefined, you have to
look in what would otherwise be irrelevant places - or trust that the
undefined behaviour *didn't* screw your system in some arbitrarily subtle
way.
Quote:
I'm not arguing in favour of undefined behaviour, just that a crash
closer to the point of error can be faster to debug than a detected
incorrect further away. Personally I would generally try and trap
conditions which would otherwise crash the program and handle them,
Right. So would I.
Quote:
on
one application I've been working on that handling can mean aborting the
program with a suitable error message.
I don't consider dev-time assertions to be crashes.
--
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
