Re: Error codes vs. exceptions
none Yannick Tremblay wrote:
In article<4fcbeaf4$0$15709$c3e8da3$fdf4f6af@news.astraweb.com>,
Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
Adam Skutt wrote:
On Jun 1, 9:44 pm, Pavel
<pauldontspamt...@removeyourself.dontspam.yahoo> wrote:
Stefan Ram wrote:
Pavel<pauldontspamt...@removeyourself.dontspam.yahoo> writes:
I know you have already received lots of advice; but I think they omit an
important factor, namely whether you are writing a library. In my experience, I
found it quite annoying when the API of a library I use can throw.
And that leads to an answer to the OP's question: When in Rome do as the
Romans do!
Surely, write a catch block?
Oh, sure. For example, if your error processing policy requires assigning
severity level to every error before logging it, you will surely be happy to
write a catch block where the severity is best known to be assigned, won't you?
Now think where in the code this place could possibly be. A little hint:
"generally" it's not in main(), regardless of whether you are handling
std::exception or other exception (unless your app/library is so small that you
"generally" call functions from other libraries in main()).
I think your problem is that you are implying and assuming that the
the best place to handle the error (assign a severity value, etc.) is
in the immediate caller.
Not for the error generated by the code under your control, no. You may have
good-for-your-purpose conventions on error models and error processing. You can
catch and process *your* errors wherever appropriate -- as you rightly describe
below.
But more likely the not an arbitrary selected library you are using does not
obey your error conventions. This is not a library writer's fault. Objectively,
a library cannot follow many useful conventions (e.g. error severity is often
specific to client code's context and cannot be determined in the library).
Therefore, you often need to *convert and enrich* error conditions signaled by
several used libraries, each according to its own conventions, to your
conventions. *These conversions* is what is usually best encapsulated in the
immediate callers (to minimize the amount of code exposed to foreign error
conventions which in turn minimizes the scope of the changes required when you
switch to another library or a new version of same library or add to or replace
your code surrounding the library calls).
Because I have been changing library writer and library user hats often and, as
library user, I found non-throwing libraries much more pliant to conversions of
their errors to the conventions required by my code, I follow the golden rule
when I am designing libraries: do to other library users what I want library
writers do to me when I am a library user -- that's it.
You may be correct that it is not "generally" in main but I disagree
with you implication that it is "generally" in the immediate caller.
With exception: you can catch and handle the error where appropriate
With return status code: you must check for the error in the immediate
caller even if you are unable to du anything about it. If it is the
case, you must then anreturn another error and so on.
a. It won't be called at the first place, because a specific exception type
won't be caught.
Generally spkeaing, catch statements should be "rare" (as in not
around every single function call). Where you catch, you may want to
catch probably one of:
- all the exceptions types you know how to handle/fix
- all exceptions (with multiple catch) and handle or log all.
Re-throw if desireable.
The above is fine -- as long as the exception type hierarchy is under your
control (that is, higher than the conversions at the call stack).
b. Even if it were somehow auto-magically called, it often would not have enough
data to fill up the logging function's arguments or the dialogue fields without
cracking the exception or error code.
What about:
catch(...) { log<< "Critical Fatal Total Error: unknown exception. We
don't know how and why it has happen so PANIC! is the best answer!"; }
This sounds reasonable to me. If some error occured and you don't
even know that such an error is possible, then you really should
consider it as critical.
It is reasonable if you cannot possibly catch this error where you have useful
information about the error's meaning *for you* (and off the bat I cannot come
up with a case where it would be *technically* impossible).
If, which is often the case, it was your choice to catch that error in a place
where you cannot read its meaning-for-you -- I would not call it reasonable. I
would rather call it a design error.
It is instructive that in some libraries designed for critical applications by
serious ISPs (e.g. IBM's MQ Series C API), the error codes were returned in
output parameters. A programmer using such API does not have a chance to fully
ignore error conditions because s/he needs to define a variable (sometimes more
than one) to hold error codes. IBM's APIs are a good example because no other
company has had more experience with maintaining huge enterprise-level
applications depending on multiple libraries. It's also instructive that some
'newer-style' and best-usable POSIX C API calls have been re-designed same way
(think of strtol() that all but replaced atol()).
I don't consider design choice for a pure C API where exceptions don't
exist as particularly relevant to a discussion on C++ error handling
which has built in exceptions and where exception is the default
language behaviour.
I am not sure I understand this statement. In my opinion, exceptions are a C++
feature, yet another tool made available to practitioners, not a behavior.
If what you mean is that the default operator new does not return 0, it is a
reasonable (although maybe not the best) default choice *for this particular
error, which is unique in that most applications will want to terminate when
they run out of memory* (I am saying "maybe not the best" because if I do want
to terminate, I would prefer to abort() (which dumps core, on many systems) as
close as possible to the call site of the failed memory allocation call to
investigate the problem easier).
On the other hand, the other errors, such as i/o or formatting errors (to which
category strtol() mentioned by me falls) are *not* signaled via exceptions by
default in C++ -- for example, you have to call exceptions() on a stream to make
it throw -- which is, I think, also reasonable. It is unfortunate, however,
that, at least in practice, you have to pay for the cost of calling potentially
exception-throwing functions even when you do not turn any stream exception on.
The above paragraph is not talking about exceptions but its subject is directly
related to the topic. Namely, if we arrange APIs error exposure design decisions
in the order from less to more prominent manifestations of possible error
condition by API functions, our order will look approximately as follows:
This is totally backward:
1. errno, GetLastError(), global variables, C++ functions without exception
specifications that throw and the likes. A programmer is not reminded about
possible error conditions in any way except possibly for the documentation.
Are you seriously grouping exceptions with errno? This is hard to believe.
In terms of giving a programmer a syntactic hint about error condition an API
can raise? Of course I do. Namely, neither of the above gives any syntactic clue
to an API user whether a function call can raise an error condition and, if yes,
how to catch it.
2. C++ functions with exception specifications. A programmer is reminded about
possible error conditions if s/he has function prototype in front of him or her
while coding the call.
3. Error return codes, A programmer is reminded about error condition as in #2
plus they may be able to turn on some "unused function return value" compiler
warning or the like.
4. Errors are encoded in output parameters of API. A programmer cannot
unwillingly ignore an error condition.
This is so back to front. Exceptions absolutely can't be ignored
passively.
You are probably talking about run-time. I am talking about coding time. At
coding time, exceptions perfectly can be ignored (and in fact quite often "the
can" is being "kicked down the road"). When this happens in a library (I mean,
ignoring the exceptions thrown by a library underlying this library), the onus
is put to the library user -- often without any notice and for their own money.
> This is one of the strongest quality of exception above
either return code or output parameters.
Error ouput parameter are easy to ignore: you just don't test them
after the function call.
please see above
One of the big problem with return code, errno or even error output
param is that nothing in the code indicates that the programmer made
the deliberate choice of ignoring the error rather than just being
lazy.
Same with the unspecified exceptions -- nothing *in the code* indicates such
deliberate choice (this is somewhat specific to C++; Java is notoriously different).
With expection, the error will *always* interrupt normal processing
*unless* the programmer explicitely write code to resume normal
processing. This is a *good* thing.
Now you are talking about run time. Also your model of "a programmer" is
limited; in a real-life application it is often that there is more than one
programmer in the picture: programmer lp1 wrote library l1, programmer lp2 wrote
library l2 that calls l1 and neglected to catch any exceptions; then programmer
ap wrote application a that calls l2 and has no clue about l2's use of l1 (it's
not ap's fault because we already know lp2 is sloppy; he did not necessary even
documented it for ap that l2 uses l1).
ap diligently catches documented exceptions of l1 at all correct points; but
once in a while his program has inexplicable problems (whose root cause are
exceptions from l1 but he won't before much later). ap just picked up the tab..
If this situation is not familiar to you, you are either extremely lucky or do
not maintain big software systems a lot.
The corrected list above is:
1- errno, GetLastError(), global variable: programmer need to test
something that is outside current scope and location. Programmer needs
to explicitely call a method or read a variable that is unrelated to
current processing in order to check if an error has occured.
2- return code: very easy to ignore or forget about. How often have
you seen the return value of printf() being ignored? Error checking
needs to be done manually.
3- error output parameter: because you have to explicitely define the
paramter, the programmer is less likely forget and compiler flags may
raise a warning.
4- Exceptions: programmer can't ignore them passively.
See above. This happens all the time and this is not even always the last
non-catching programmer's fault.
> The only way
to ignore exceptions is to explicitely catch them all and
continue. Error checking is automatic.
The code to capture error codes is simpler,
shorter and faster than that needed to capture exceptions.
I don't see how it can ever be less code than exception handling[4].
- It is simpler because error codes are easier tabulated for their
classification or another mapping (potentially driven by the rules that are
configured externally to the program and that are to be applied to programs in
other languages than C++) to the entities required by the application error
handling policy.
- it is shorter (especially with error-code-based or errno-based approach to
error propagation) because well-encapsulated error-checking code is notably
shorter than equally well-encapsulated try {} catch{} code. E.g. compare:
Only for poor quality code!
?
if (!handleError(apiCall(args..)))
return;
or
if (!apiCall(args..)&& !handleError(errno))
return;
to
try {
apiCall(args..);
} catch(XxxException&e) {
if (!handleError(e))
throw;
}
Arggh! Typical problem with error return code apologists. You are
doing it wrong. You are unable to change your mindset of handling
error for each function call one by one. Write the normal path,
handle errors where appropriate. The above is an perfect example of
poor quality code.
You are missing the point. Whether or not you have to convert every error of 3rd
party library into your error is often not a choice but a requirement.
Exception code should (at worse) look like:
void foo()
{
try
{
// Normal path
// several lines of code
// implement all the normal processing logic here sequentially.
}
catch( /* something */ )
{
// handle errors
}
}
In many cases, it should look like:
type2 foo1()
{
bar1();
bar2();
bar3();
type t = bar4();
type2 z = bar5(t);
return z;
}
bar1()
{
buzz1();
buzz2();
// ...
}
boss()
{
try
{
type2 t = foo1();
foo2(t);
// ...
}
catch( /* stuff */)
{
// handle errors
}
}
The amount of error handling code can easily become 1/4th to 1/10th of
the amount used by return status code style programming.
/* if apiCall does not encapsulate exceptions from *its library's* underlying
libraries, the above code would be even longer */
- it is fater because compiler can optimize nothrow code. In a (probably futile)
attempt to prevent pointless objections to this statement I am referring you to
the Ultimate Authority of the Standard, see a footnote to 17.4.4.8-2 in ISO/IEC
14882:2003(E) or 17.6.5.12-3 in ISO/IEC 14882:2011(E) about the reason why C
library functions shall not throw:
Why are you talking about C library functions?
I am not talking about C library functions. I am talking about the fact that the
authors of the (C++) Standard recognized and explicitly acknowledged that
implementations can optimize functions explicitly declared not throwing. (From
half-empty glass perspective, by that they admitted the significance of
pessimization caused by throwing functions).
Of course C library
functions shall not throw.
It would be instructive for you to read the footnotes I referred to to learn
*why exactly they shall not throw* (from the viewpoint of C++ Standard authors,
not mine).
C doesn't have exceptions.
Even if this is a rationale of C++ Standard authors for requiring C functions to
be no-throw, it is not written down in the Standard. The performance rationale
is written down.
We are
discussing C++ here!
And I am fully aware of that. And you are fully aware that I am aware.
It's slower because you have 100 if/else statements in the normal path
where I only have 1 try/catch
It does not make sense to compare the amount of ifs in the pieces of code that
do different things. My two code snippets are comparable to each other in their
functionality (a uniform and informed handling of all error conditions of a
3rd-part library. I defined this purpose for your multiple times). Your code
snippets are doing something else. It would be useful if you defined the purpose
of your code before writing it.
It is slower because in the normal success processing path, you
repetitively have to check for error while with exceptio
e.g. compare:
// Critical loop:
for(int i = 0 ; i< BIG_NUM ; ++i )
{
int retVal = foo();
if(SUCCESS != retVal)
{
// handle error
// break/return/exit?
}
}
vs
try
{
for(int i = 0; i< BIG_NUM; ++i)
{
foo();
}
}
catch(...)
{
// handle error
}
The normal path has at least 1 more assignment and 1 more test. Things
become even worse if the function actually return a value (see below)
The Extra assignment is only in your code because error processing is not
encapsulated (see my code snippet above that does not have that assignment). Of
course, even the way you wrote it, the assignment does not have to appear in the
machine code at all.
It's slower because you have to define a object with dummy value, pass
it as argument to a function, copy data into it then finally use it
while I initialise the object directly with valid value and the
compiler can optimize the code with NRVO/RVO
With return codes, you do not have to pass extra parameters. If you allude to
not being able to return value along with parameters, you can always group the
return code into std::pair. STL containers sometimes do just that. RVO works
just fine on a pair; often the return value and return code never hit main
memory -- as long as there enough registers. Of course, return code does occupy
a register -- but exception and overhead of a throwing function's
prologue/epilogue cost much more than one register.
It is slower because the compiler can't optimize code as nothrow
simply because there are no explicit throw/try/catch statements in
your code.
Yes, it can and it does. Please refer to the Standard and study the assembler
code I posted earlier in the thread "Using printf in C++" or generate and study
the code of your own.
If anywhere down the line something uses the C++ standard
library, new or an allocator, then exceptions may occur.
That they can. What they can't is to be thrown from the function declared as
no-throw. std::terminate() will be called first (and std::terminate() does not
return -- or throw).
".. This allows implementations to make performance optimizations based on the
absence of exceptions at runtime."
In C++, that's playing ostrich. (as in bury your head in the sand and
claim it's not there because you can't see it) You should always
assume the any function call can throw.
At best, it can be equal, and in practice, it must necessarily be more
because you're explicitly doing things that are done implicitly with
exception handling.
Whom do you mean when you say "you're"? Me a library writer or me a library
user? Me a library writer is supposed to go extra mile to better serve a library
user. Me a library user will have to do more and more complex things when I use
exception-based API which my this and previous and previous-before-previous
posts explain at monotonously increasing and unnecessary for a reasonable reader
level of details.
Strongly disagree. As a library user it is much simpler to use an API
that is exception based than an API that is return code based.
Not if you need to process errors according to strict policies about which the
library author did not and could not know when s/he wrote it.
As a free bonus, you (or your user if you are the library writer) can always
make a choice between writing throw and nothrow functions at no coding cost.
Hardly. Just returning error codes doesn't suddenly let you mark
everything nothrow,
It allows you to "mark everything nothrow" without writing try-catch blocks.
Marking functions nothrow was not counted as part of the cost because it had to
be done regardless of the type of the underlying API if the decision to write
nothrow functions has been made.
There you are again playing ostrich. As discsussed by others in this
thread, if you want nothrow, you must never use new or the standard
C++ library anywhere and you must enable the "no exception" flag in
your compiler.
A compiler with enabled "no exception" flag is not a standard C++ compiler (at
least it was not according to the old standard; I did not check the new one at
this).
As for never using "new" under a no-throw function this is another fallacy,
easily disprovable in practice at that. Please try this simple test on your
favorite most compliant C++ compiler (with the exceptions turned on):
#include <iostream>
#include <vector>
using namespace std;
void
memoryBuster() throw()
{
vector<double> v(10);
for (;;) {
v.resize(v.size() * 2);
}
}
int
main(int, char*[])
{
try {
memoryBuster();
} catch(...) {
cout << "memory buster has thrown" << endl;
}
return 0;
}
With a compliant compiler, you will get:
a. with uncommented throw() specification: terminate() called and no "memory
buster has thrown" output.
and
b. with commented-out "throw()" specification: "memory buster has thrown" output.
Anything else is unsafe.
due to the problem I mentioned above.
On top of this, following the code that only calls nothrow methods is much
easier which increases the programmer's productivity.
I fail to see how calling a method marked nothrow increases my
productivity at all.
As the rest of the paragraph explained, in increases your productivity by
reducing the time you need to read and understand the code with only explicit
exit paths. Oh, I forgot, you are not spending much time reading code.. this "on
top of it" advantage is probably not for you then.
Strongly disagree. In my experice, reading exception based code is
much simpler since I can read the normal success path and concentrate
on the sanity of the success scenario independently of the error path.
I can then read the error path and concentrate on the sanity of the
error path.
And where are you going to search for the error path? Throughout the whole code
base?
And since the code is typically significantly smaller,
The code that is functionally equivalent will be of comparable size (depending
on the required functionality, slightly smaller or slightly bigger. In my
experience, when you need to adhere to a strict non-trivial error-processing
policy, it is slightly bigger).
I
have to spend less time reading.
Typical error return based code in C++ is a nightmare to review. It
is typically exception unsafe because it blindly assume that because a
specific function implementation does not has explicit throw
statements, then exceptions can be ignored.
How is this relevant to my post? My post recommends to design a library API from
no-throw functions. And, if a function is declared no-throw, then, *yes,
exceptions can be ignored*. In fact, you do not have any other useful choice
when you are calling a no-throw function *because you are never going to catch
an exception from it, neither at call site, nor in main(), nor anywhere in
between*.
As a result the code will
often be totally exception unsafe and if anything below generate an
exception, then everythign breaks.
irrelevant to my posts.
Even ignoring this simple fact, the repetitive "doA, check if A
succeeded, handle A-type error, decide if processing can continue, if
not release previosuly acquired resources, doB, check if B succeeded,
handle B-type error, decide if processing can continue, if no release
previously acquired resources including those acquired for doA, ... "
is very verbose and very error prone.
irrelevant to my posts.
It doesn't reduce what I need to be worried or
concerned about unless the code actually provides the nothrow safety
guarantee, which is considerably difficult.
Really? Valid C++ code that does not throw any exceptions itself and calls only
functions with an empty exception specification is guaranteed not to throw an
exception. Incidentally not throwing an exception *is* the definition of nothrow
exception safety guarantee.
please review what "nothrow" actually does and what are the
consequences if a function declared as nothrow does let an exception
escape.
Please follow your own advice and review what non-throwing functions (those
declared as throw() or equivalently) do and memorize once and for all that they
do *not* "let exceptions escape".
Merely not throwing exceptions is of very little benefit to the
programmer.
I am not sure about that vague "merely not throwing exceptions" but exposing
only no-throw functions from a library API (which was my original and only
point) brings all the benefits I claimed.
It brings some benefits for some style of programming. It however
bring cost for some other style of programming. I prefer an library
that uses exceptions. Much easier to use.
Let's take the Eigen library for an example:
MatrixXd m(2,2);
m(0,0) = 3;
m(1,0) = 2.5;
m(0,1) = -1;
m(1,1) = m(1,0) + m(0,1);
Why don't you define the required error-processing functionality of your
application before writing any code for a change?
Very usable. Now let's try to rewrite this with error code:
MatrixXd * pm = MatrixXdFactory(2.2);
if(NULL != pm)
{
int retVal = 0;
retVal = pm->Set(0,0,3.0);
if(0 == retVal)
{
retVal = pm->Set(1,0,2.5);
if(0 == retVal)
{
retVal = pm->Set(0,1, -1.0);
if( 0 == retVal)
{
float v1 = 0;
retVal = pm->Get(1, 0 ,&v1);
if( 0 == retVal)
{
float v2 = 0;
retVal = pm->Get(0,1,&v2);
if(0 == retVal)
{
float v3 = v1 + v2;
retVal = pm->Set(1, 1, v3);
if(0 == retVal )
{
// Success!!!!
}
}
}
}
}
}
}
}
}
It is completely pointless to evaluate the code above whose only purpose IMHO is
to demonstrate strangely looking code. Neither snippet tells me anything about
how either retVal or (invisible and unhandled, contrary to all your "impossible
to ignore" statements) exception is intended to be dealt with.
Specify the possible error conditions and desired error processing policy of
your library, specify how the exception version of the API signals these
conditions and demonstrate how you implement your specified policy over it and I
will show you how to implement same policy with an alternative
(non-exception-based) error-signaling API in a competitively clear and concise
code.
Please notice that I have already specified the case (which is often in
enterprise applications practice) where the code based on exceptions is
necessary bulkier.
// handle error?
return retVal;
Yuck!
Bon appetite
Feel free to rewrite the above with error output parameters to
demonstrate how much better again the code would be and how much
easier to read and review.
I will gladly do so when I understand your desired error handling policy and see
your code that is compliant with it.
Yannick
-Pavel