Re: Testing Program Question
On 12 Feb, 21:50, "Leigh Johnston" <le...@i42.co.uk> wrote:
It's not clear what types of errors you have in mind.
Programming errors are generally best handled by immediately
aborting, at least in production code, at least in most
application domains. Depending on circumstances, other
errors are best handled with exceptions or return codes.
Programming errors are best handled by fixing them,
Programming errors are best handled by preventing them in the
first place: carefully specifying each function, and reviewing
the code which uses the function against the specification.
assert can help in this endeavour but *usually* only in debug
builds: release build asserts are best suited only where a
higher level of defensiveness is required, not for your
typical desktop application.
Asserts are a sort of life jacket, to prevent things from
fucking up too much when you screwed up. Removing them from
production code is akin to wearing a life jacket when practicing
in the harbor, but taking it off when you go to sea.
Sometimes, it's necessary to remove asserts for performance
reasons, and for some particular applications (games?), it's
probably preferrable to remove them completely (in which case,
you do have to study what happens when they are
removed---there's no point in removing an assert if you're just
going to get a crash three statements later).
With regards to "typical desktop applications", I'm not too sure
what you mean by that. As I said, games are a possible
exception, where removing asserts makes sense. But which is
preferrable for an editor: that it crash, leaving you to recover
using its last check-point save (5 seconds or 5 keystrokes
before the crash), or that it stumble on to overwrite all of
your data, and save that at a check-point before finally
crashing?
Genuine runtime errors (e.g. out of memory, disk space or user
input error) are best handled by exceptions or return codes.
Agreed. Any program which has an assertion failure on user
input error is broken, and the same probably holds for out of
memory, although it's discutable for some applications. (What
happens if the "out of memory" occurs because the runtime is
trying to grow the stack? Or if the only possible cause of "out
of memory" is a memory leak? Or simply that your OS doesn't
handle "out of memory" safely?)
--
James Kanze