[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