Re: Exception handling Organization: unknown
"Alan McKenney" <alan_mckenney1@yahoo.com>
if(!(f = fopen(...))) crap!
if (!read(f...)) crap!
if (!read(f...))crap!
Funny thing about that.
My most recent experience with exceptions was
with an API which used exceptions for error
reporting.
My code ended up being in the form:
try { call_1(...); }
catch ( Except & err )
{ log( "call_1 failed (err %d) %s ... ", ... ); return }
...
try { call_2( ... ); }
catch ( Except & err )
{ log( "call_2 failed (err %d) %s ... ", ... ); return }
That's the canonical smell of using exceptions the bad way.
Though in your layout it can be handled differently:
const char * func;
try {
func = "call_1";
call_1(...);
func = "call_2";
call_2(...);
...
}
catch // ... log func and result
You can even get rid of the trash using a macro like
#define CALL(funcname) func = #funcname; funcname
CALL(call_1)(....)
With error returns it can't be done so easily, especially if the calls
return different types.
(Type and function names changed to protect the guilty.)
That's because the information I want to log depends upon
which call threw the exception, and the error object doesn't
say which call it was.
In most situations I had it was not at all interesting which invocation
threw. The information in the exception was enough to know the real source.
Like for file exception, the path of the file. Do I care which of the 999
reads failed to log it?
It would have been easier with error returns.
If really so, I write wrapper function to the API call that converts the
exception to return code, and call the NT version. Certainly that works
only for a subset of cases -- as you have only one return slot, that
functions are happy to use for work. And problem situations can be colorful
enough too.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]