Re: Error codes vs. exceptions
"mike3" <mike4ty4@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 then
clients can use the better-suited variant.
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.
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.
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, but
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.
Does this mean that we should prefer exceptions in that case, to allow it
to
propagate up to a higher level where something may be able to be done, even
if the error is not "exceptional"? Whereas if we can handle it on-the-spot,
we
should use an error code? E.g.
By using the previously mentioned form you already admitted that the error
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?
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.
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). The
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.