Re: Error codes vs. exceptions
On Jun 3, 7:05 am, "Balog Pal" <p...@lib.hu> wrote:
"mike3" <mike4...@yahoo.com>
Is it a good idea to default to exceptions for errors, and then if after
you start actually using the code, it looks like an error code is more
appropriate, to use that instead?
Yes. As I mentioned for some operations there's a need for both forms.
Fortuneately it's not hard to write converters in either direction, and t=
hen
clients can use the better-suited variant.
So then you _do_ need a translation layer than translates error codes
to exceptions and exceptions to error codes, and thus need a 1-to-1
correspondence between the two, with exception classes for every error
code in your error code enum (it seems that in the examples in the
C++ "bible" (Stroustrup), they have exception classes for every type
of
exception that can occur. Also, I've heard stuff about not including
type
fields in exceptions, and type fields being a bad idea in general, and
it's
better to use different classes + inheritance instead of type
fields.)?
And thus the need to update several statements in the program when
adding new errors: update the error code list and add a new exception
class and also update the translator.
So perhaps maybe I should call an exception :) to the no-type-field
rule
because it's causing gains in complexity and a reduction in
maintainability?
Then we only need to add codes to the error code list and don't need
to
mess with anything else. After all, the rule is supposed to help
maintainability,
so if you're running into a situation where it's hurting it, better to
call an
exception to the rule. Remember that programming is not based on hard
rules. Or don't bother with two-way translation, and allow for
separate and
distinct sets of error codes and exceptions.
(Why is a 1-1 correspondence needed? Because consider if the sets
are different: How do we determine what to translate to? Suppose we
have
error codes for "XPARAMOUTOFRANGE" and "YPARAMOUTOFRANGE"
but only a single "OutOfRange" exception. We can translate the codes
to exception, but how can we do the reverse translation? There's an
ambiguity.)
OTOH raw input form a user/outside world can be anything, so first it
must
be checked/sanitized. Failure is properly expected.
So does this mean the functions processing the input should return
error codes, with all their messy glory?
Don't confuse the situations and it's not that messy really.
What's messy is this:
---
retVal = doSomeErrorCodeReturningFunc1();
if(retVal != SUCCESS)
{
Handle it. May include a detailed response, may just "log" or
report message.
}
retVal = doSomeErrorCodeReturningFunc2();
if(retVal != SUCCESS)
{
Might do the same thing as before! Oops -- code smell: duplicated
code.
}
retVal = doSomeErrorCodeReturningFunc3();
if(retVal != SUCCESS)
{
Ditto.
}
---
And even if we have no code duplication, we may nevertheless turn
a "short method" into a "long method" -- code smell.
And this is "error-reaction logic tangled up with action logic" -- see
below.
I've got a thread going on comp.lang.c about this same thing -- where
in C, exceptions do not exist. The above seems very "Cish".
In that layer you will have functions that return status. IsEmailValid()
shall not throw, but return bool, or some more detailed info on the
diagnosed problem. When you check the input you will call a ton of such
functions, and the caller will know how to act on discrepancy.
No, and I would not expect such a function to throw, either. It's
after
all, a validity _checker_.
While those functions return "error code", it is not really that from the
function's perspective: it does all its work properly and that is the
result. It only becomes error code if the caller decides to not act, b=
ut
pass it upwards.
So does this mean to prefer an exception, since then we can do "x = f=
() +
<foo>"?
Yes, that is the main motivation. To separate the action logic and the
error-reaction logic. Not mix and tangle them together.
So does this mean my original idea:
1. throw exceptions from functions whose return value would not be an
error
code but a useful result (or throw from constructors, since they
_can't
return anything_, and to throw from overloaded operators)
2. throw error codes from functions that would otherwise return "void"
was right?
This idea seems to suggest prefer exceptions, and not limit them to a
minority
of errors, otherwise in the majority of errors we'll be mixing
reaction logic with
action logic (see above).
Does this mean that we should prefer exceptions in that case, to allow i=
t
to
propagate up to a higher level where something may be able to be done, e=
ven
if the error is not "exceptional"? Whereas if we can handle it on-the-sp=
ot,
we
should use an error code? E.g.
By using the previously mentioned form you already admitted that the erro=
r
condition *is* exceptional.
If that invocation form is correct, it implies that
- involved operations are expected to succeed
- this spot has no interest in looking at error conditions
If the code expected some problem and had alternative actions in mind for
that condition, it would be there, wouldn't it?
Ah.
So then... "good idea to default to exceptions for errors, and then if
after
you start actually using the code, it looks like an error code is more
appropriate, use that instead"?
Yes. Certainly don't forget to provide at least the basic exception
guarantee, and learn about tha Abrahams principles if you didn't yet.
Hmm.
So it's OK to keep a distinct set of exceptions that's different from
the list of return codes?
Those facilities serve some purpose. If you meet that purpose you're okay=
..
Does not matter how you do that.
In usual good code 95% of catch() blocks just do a conversion to some
different exception or a return code.
The rest minority that actually does something -- and it will just catch
*any* exception (with luck the common base class for all), and just call
.what() for a single string.
And that is more than enough. Top levels only care if stuff worked or not=
..
Rollback actions are issued via destructors (or simply lack of commit). T=
he
inforlation on the problem trigger is carried in the exception object and
can present itself to a human-readable form so some actual intelligence,
outside the program can figure out what next.
So then a translation layer (error codes <-> exceptions) is vital. So
what
about the problems mentioned at the beginning of this post?