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.
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
I wonder how you arrived at that conclusion.
The conversion is there tof *practical* purposes, and does exactly what is
considered practical. It may swallow some conditions, turn everrything into
bool, or whatever. A possible approach is to have a single exception class
with just a string, and the converter fetches the error string from the
source (like perror) and emits that.
You'd need the original enums only if planned to act on them, but if you
want that, you don;t use the converter in the first place, but call the
original.
(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.)?
Another practical design question. I already suggested to start with the
code that acts on the error condition, then design all the rest to supply it
the proper info in the most convenient form.
And thus the need to update several statements in the program when
adding new errors:
If you replace the library to one woth a different specification (like the
function you called this far changed its return codes, and added some new
ones) you certainly need to update the code. If unused parts of the library
do anything, including undergo extension or changes, it should not change
your existing code in any way.
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.
I have an impression that you chase made-up problems instead of dealing with
real ones.
Watch the baton not the runners.
(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.
And as you're supposed to pass both params strictly in-range, all of those
are obsolete.
And as a debug aid during development you use assert in the function. If you
really want the excepton a single string-exception with those quotes shall
do.
We can translate the codes
to exception, but how can we do the reverse translation? There's an
ambiguity.)
Why would you want the reverse translation?
.....
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).
In so many words.
So then a translation layer (error codes <-> exceptions) is vital.
No it is not, just is pretty common. Mostly because we use external
components, all following their own style and we translate those to fit our
system if the difference is big.
So what about the problems mentioned at the beginning of this post?
You made those up ;-> to a fair level.