Re: Error codes vs. exceptions
"Adam Skutt" <askutt@gmail.com>
Simple guide is that you use return code if the immediate caller is
supposed
to care about the failure details and act. While throw is for long-range
communication. Not surprizingly for some functions both make sense.
I would love an example of this, because I've never seen such a
determination made, much less correctly.
MFC's CFile class has:
-ctor that takes filename, opens file and throws CFileException on a
problem.
-ctor that takes nothing and does not open the file
..Open() that takes filename, opens and return TRUE on success.
So where I expect the file to be there, I use the first form.
In other case the second. It's not at all uncommon to look for a file at
multiple different locations, all being optional. Or attempt to write a file
at some sensible location and fall back to ask the user if it can't be
created there.
The ability to make such a determination is extremely rare, including
for invalid input. Exceptions should be the normal response to
invalid input to a function, including to invalid input supplied by
the outside world.
That opens slippery slope for mixing program logic errors with environmental
factors outside our control.
Depends on what is asking. If your program code that should have obey the
bounds, then it is a completely different field, that of assert() and
terminate() due to detected bug.
Perhaps, if you can determine it was programmer error. I'm not sure
the different behavior is really justified in the few cases where that
is possible.
Come on! If a function has a precondition, then the programmer, the caller
is responsible to meet it.
If it is not met, it *is* a programmer error. Not cosmic rays or wrath of
God or anything.
And IMO systems based on contracts was beating those without anywhere in the
real world.
Throw exception? See, what I've currently been doing, and
it's probably silly, is to use exceptions when our function needs to
return a value, and error codes when it could otherwise return "void".
Certainly the function is hosed. :) exception looks like the easy way
out.
But that holds only locally. If the caller thought the bounds were okay,
and
turned out wrong, who shall handle the exception and how?
Perhaps no one, and that's perfectly fine. Just because an exception
is thrown doesn't mean it needs to be caught ever.
It is not fine. If the program derailed, it is in a state its creators
thought be impossible, any further action has fair chance to make thing even
worse. Unwinding the stack to some default habdler before exit IS further
action. Even if there is no handler, C++ does not specify whether stack
unwinding happens or not before terminate() gets called.
So throwing instead of halting is a fishy practice.
Also, in a program written in C++ that has any basic quality controls the
most likely cause hitting an assert failure is undefined behavior. And once
the behavior is undefined, do you think further will be good?