[prog] C programming - capturing information sent to stdout
Sue Stones
suzo at spin.net.au
Thu Jul 14 11:53:38 EST 2005
Mary wrote:
>Robust programs in production would never have asserts that fire under
>conditions they expect to be reached during normal operation (which
>includes expected errors). Debugging is a different ballgame :)
>
Yes but I am asking where the boundaries of that expectation are. At
one level you could say that if you know enough to put a assert
statement in there then you are expecting an error, so assert shouldn't
be used. Using assert to determine if preconditions have been met, says
that you expect that some programmers will not comply with the
preconditions, so assert shouldn't be met.
I am not talking about opening files in a visible way like open office,
but behind the scenes stuff that the user doesn't know about, but which
would should be fatal. If the alternative is to crash the program when
this error occurs is assert acceptable?
If a program is invisibly using a file or opening a pipe, which side of
the border does this fall on? As programmers we know that there may be
problems creating a file, or opening a pipe, but less experienced people
may not consider them. Does this fall into the category with unmet
preconditions (the precondition is that the program has read and write
permissions in the relevant directory, and enough space to use it). Or
does it fall into the category of "some users may not know this needs to
create or read files and will use it where this is impossible" so we
need to write our own error message and crash the program manually.
My question is when the desired outcome of a failure to open a file *is
to crash the program* is assert the right way to do this, or are these
problems common enough that they need to be crashed explicitly?
sue
More information about the Programming
mailing list