G
Gianni Mariani
I'm involved in a new project and a new member on the team has voiced a
strong opinion that we should utilize exceptions.
The other members on the team indicate that they have either been burned
with unmaintainable code (an so are now not using exceptions). My
position is that "I can be convinced to use exceptions" and my
experience was that it let to code that was (much) more difficult to debug.
The team decided that we'd give exceptions a go. Yeah for progress !
I've been rattling my tiny brain on the issue and I have come to the
conclusion that exceptions are not as flexible as status codes.
a) For debugging purposes we want stack traces - but only for cases
where the exception is caught in a place we consider a "bad" thing happened.
For example, say we have a "file" object that fails to "open" the file.
In most cases, it's ok, we don't really care, it's really not
exceptional except if it's an "important" file. I really don't know if
it's important at the lower levels (where the exception is thrown).
I'm ok with psuedo stack trace e.g.
T func( T0 arg0, T1 arg1 ... )
try
{
... func magic ...
}
catch ( ... )
{
LOG( "func", arg0, arg1 ... ); //etc
throw; // rethrow
}
This does not look too bad but it's not foolproof because no-one knows
which of the arguments actually make sense to log at any point in time.
I suspect there are also optimizer hits because the values need to be
stashed away "in case" of exception while in regular code we would be
logging the arguments like:
if ( ! func( v1, v2, v3 ) )
{
LOG( WARNING, "func() Failed", v1, v2, v3 ... );
return falase;
}
And hence only if "WARNING" level logging is turned on do the values
need to get stashed.
b) It would really be nice to know what is going to catch an exception.
I know this is a bit of a wild thought but it would be nice if there
was a low-cost was of throwing context dependant exceptions. I suppose
we could do that using a TSS variable if we had co-operating
caller/thrower semantics.
I know this is a contentious topic, I really don't want to start another
exception war, but I'd really like to hear from people experienced in
using exceptions in big complex projects and the things to avoid and
techniques to use to get the best bang for sweat.
The usual rules are clear.
1. assert for logic errors - absolutely no exceptions used to detect
logic errors.
2. exceptions should occur infrequently in "normal" running of the code.
3. RAII everywhere etc.
I'm more interested in fine tuning.
G
strong opinion that we should utilize exceptions.
The other members on the team indicate that they have either been burned
with unmaintainable code (an so are now not using exceptions). My
position is that "I can be convinced to use exceptions" and my
experience was that it let to code that was (much) more difficult to debug.
The team decided that we'd give exceptions a go. Yeah for progress !
I've been rattling my tiny brain on the issue and I have come to the
conclusion that exceptions are not as flexible as status codes.
a) For debugging purposes we want stack traces - but only for cases
where the exception is caught in a place we consider a "bad" thing happened.
For example, say we have a "file" object that fails to "open" the file.
In most cases, it's ok, we don't really care, it's really not
exceptional except if it's an "important" file. I really don't know if
it's important at the lower levels (where the exception is thrown).
I'm ok with psuedo stack trace e.g.
T func( T0 arg0, T1 arg1 ... )
try
{
... func magic ...
}
catch ( ... )
{
LOG( "func", arg0, arg1 ... ); //etc
throw; // rethrow
}
This does not look too bad but it's not foolproof because no-one knows
which of the arguments actually make sense to log at any point in time.
I suspect there are also optimizer hits because the values need to be
stashed away "in case" of exception while in regular code we would be
logging the arguments like:
if ( ! func( v1, v2, v3 ) )
{
LOG( WARNING, "func() Failed", v1, v2, v3 ... );
return falase;
}
And hence only if "WARNING" level logging is turned on do the values
need to get stashed.
b) It would really be nice to know what is going to catch an exception.
I know this is a bit of a wild thought but it would be nice if there
was a low-cost was of throwing context dependant exceptions. I suppose
we could do that using a TSS variable if we had co-operating
caller/thrower semantics.
I know this is a contentious topic, I really don't want to start another
exception war, but I'd really like to hear from people experienced in
using exceptions in big complex projects and the things to avoid and
techniques to use to get the best bang for sweat.
The usual rules are clear.
1. assert for logic errors - absolutely no exceptions used to detect
logic errors.
2. exceptions should occur infrequently in "normal" running of the code.
3. RAII everywhere etc.
I'm more interested in fine tuning.
G