Re: I keep running into long term c++ programmers who refuse to use exceptions
On Mar 7, 8:31 am, "Nevin :-] Liber" <ne...@eviloverlord.com> wrote:
[...]
Take std::find. Is it really "failure" if it returns its second
parameter?
No, it is part of the contract.
But the problem is the find function's dual duties: (1) return whether
or not the item exists in the range, and (2) return an iterator
pointing at that element. Those returns are not the same type (the
first is logically boolean). So a special iterator value, the end of
the range, is used to represent "not found".
Many functions are designed like this for the simple reason that the
work needed to perform (1) and (2) is nearly the same, and splitting
it up in two functions would duplicate work.
As it happens, this can be avoided with stateful programming in C++,
but it has never become fashionable as far as I know:
Finder f (c.begin (), c.end (), element);
if (f.has_element ())
Iterator i = f.locate ();
Whether or not Finder::locate is designed to throw for non-existant
elements may depend on its run-time requirements. Efficiency may be
important and it does no checking, leaving its behaviour undefined in
that case. Or safety may be important and it checks and throws.
Alternatively, you can have two members, one checked and one unchecked
("locate" and and "unchecked_locate"). This interface design is
similar to std::vector::at and std::vector::operator [].
This stateful idiom is applicable to many other dual-return functions
as well. I have found good use for it in geometry libraries. E.g. for
intersection:
Intersection i (line1, line2);
if (i.exists ())
Point p = i.locate ();
The technique is especially useful in this example because the
constructor does only the work needed to determine if the intersection
exists and the remaining work to locate the intersection is only done
when needed. This can eliminate work if you are only interested in
whether or not the intersection exists:
BOOST_FOREACH (const Line& a, lines)
if (Intersection (a, b).exists ()) ++count;
If you know that the intersection exists then you can eliminate a
branch (a potentially slow construct in modern CPUs):
Intersection i (line1, perpendicular);
assert (i.exists ());
Point p = i.locate ();
The traditional intersection function cannot do this. It encapsulates
the branch:
Point p;
bool success = intersection (line1, perpendicular, &p); // 3rd arg
is out-param
assert (success);
Doesn't it really depend on whether or not the caller
expects the element to be in the range being searched? What if the
caller looked like:
// Bug if element is still in c
assert(std::find(c.begin(), c.end(), element) == c.end());
assert (Finder f (c.begin (), c.end (), element).has_element () ==
false);
If std::find, instead of returning c.end() to indicate the element isn't
in the range, threw find_exception, the code would be a bit messier, as
in:
#ifndef NDEBUG
// Bug if element is still in c
try { std::find(c.begin(), c.end(), element); assert(false); }
catch (find_exception&) {}
#endif
Throwing an exception for "find" is clearly wrong design. One of the
dual duties of "find" is to return whether or not the element is in
the range. A false outcome of that predicate is generally expected and
not an exception (inside "find" itself, that is).
On the other hand, asking "find" to return an iterator to the element
when it doesn't exist can be viewed as impossible and warrant an
exception. But that dilemma stems from the dual duties of the
function, which can be solved by splitting it up as I've shown above.
The inversion of having failure detection inside a try block and having
success be the empty catch block makes this code much harder to
understand, yet there really is no way around it if you are using
exceptions instead of return codes, because the callee, not the caller,
has to decide what is "success" and what is "failure".
True in your example, but not in general. I think you are generalising
using a faulty example; the dual duty "find" function which is clearly
designed not to throw exceptions. I've shown above that with a
different design (Finder) it may make sense to throw an exception if
you ask for an iterator to a non-existing element (similar to an out-
of-range index causing an exception in std::vector::at).
Things that are expected to be handled directly by the caller are
usually sent in return codes; things that are expected to be handled at
a much higher level are usually sent via exceptions (at least in the
code that I have influence over).
I need a more convincing argument for error return codes than that.
The only plausable argument I've seen is performance, and even that I
suspect is rarely applicable.
Regards,
Vidar Hasfjord
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]