Re: Error handling idioms
Gavin Deane wrote:
I absolutely agree with the principle of code communicating intent.
However, for someone to say "exceptions are for error handling only"
is meaningless without a definition of "error".
"Error" is something opposite to "state". Error is violation of any
conventions, for example:
inline void zfill(char *const dst, const uint size)
{
if(!size)return;
//it is not error, because some arrays can have zero size
if(!dst)return;
//it is not error, because some arrays can be not allocated
memset(dst,0,size);
}
I would not regard those conditions as errors either, assuming (as I
think you do) that the function is intended to handle zero size arrays
and null pointers.
There is no only one answer here. Whithout any additional condition it can
be either error, or not. The best choice to remove the undefined behavior is
strcit definition of the conditions of error. For pointers, the additional
precondition is often "to be non-zero", as the following example
//do not post dst==0
inline void zfill2(char *const dst, const uint size)
{
if(!size)return;
if(!dst)safe_throw<err_zptr>("zfill2: dst");
// it is error, because we have required from client
// does not post NULL for "dst"
memset(dst,0,size);
}
That's situation can only arise if there is a bug in the calling code.
Yes. It is a bug in caller code, becasue we are assuming programmer can read
comment: "do not post dst==0". Unfortunatelly we can not detect the error at
compile time, so we need exception here, because we can not resolve the
error inside "zfill2" and can not quietly return, because all other correct
parts of code will expect correct zero filled buf.
I agree that you may want to do something in the function if the
precondition is violated. And you might decide that throwing an
exception is the thing you want to do.
We do not want, we are forced to return control into caller, because we do
not know what to do with the error and what part of program executed.
In reliable systems some failed parts of program can be easy stopped with
the help of exception and all other parts will continue to work, in spite of
all of them is sharing common libraries.
I think the best way to do separated reliable parts of program is process or
thread, but some small parts of program can be separated by C++ tools with
try/catch, without making tons of threads.
enum{ parts=10 };
void err_msg(const uint);
typedef void (*foo)();
extern foo part[parts];
extern char state[parts];
int main()
{
try{
memset(state,!0,parts);
for(;;){
for(uint p=0; p<parts; ++p)
{
if(state[p])
try{ part[p](); }
catch(...){ state[p]=0; err_msg(p); }
}}
}
catch(...){err_msg(parts);}
}
By the way, the desire of C++ often to call "terminate" instead of possible
"throw" anything to up level (that can be catched with "catch(...)")
contradicts to reliable system requirements. The known C++ error points are:
- call "terminate" if exception has been thrown in function declared as
"throw()"
- call "terminate" on "double throw".
But as this situation can only
arise in an incorrect program, your example doesn't tell me anything
about the distinction between "failures" and "errors" in a correct
program.
This situation can only arise in a program, developed with independent parts
(in fact in each program). I do not speak about differences between
"failures" and "errors" only about differences between "state" and "errors".
Any "state switching" can be, but must not be resolved by exceptions.
--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new
"In thi world of fairy tales rolls are liked olso"
/Gnume/