error codes — some clarifications

In this post I would like to discuss two issues brought up by the readers regarding previous posts on using <system_error>:

1. Storing 0 in error codes, and using non-0 success values.
2. Concerns about using globals.

Advertisements

Using error codes effectively

In the previous posts we have seen what error codes and error conditions are. But the way we used them is far from optimum. In particular, the implementation of FailureSourceCategory::equivalent was huge and error category FailureSourceCategory was forced to be aware of all error codes from all sub-systems in the project. In this post we will see how we can do better, especially in more complex systems.

Your own error condition

In the previous post we have seen how you can create your own error-code enumeration for representing different reasons for failure in your component, and how you can store them and convey them type erased via std::error_code. In this post we will see how you can inspect an error situation encoded in std::error_code, and how you can build useful queries about error conditions.

Your own error code

I was recently implementing the “classification of error conditions” in my application offered by the functionality behind std::error_code. In this post I want to share some of my experience and insight.

C++11 comes with a quite sophisticated mechanism for classifying error conditions. You may have encountered names like “error code”, “error condition”, error category”, but figuring out what good they are, and how to use them is difficult. The only valuable source of information on the subject in the Internet is a series of blog posts by Christopher Kohlhoff, the author of Boost.Asio library:

• “System error support in C++0x – part 1”
• “System error support in C++0x – part 2”
• “System error support in C++0x – part 3”
• “System error support in C++0x – part 4”
• “System error support in C++0x – part 5”

And this was a really good start for me. But still, I believe it would be beneficial to have more than one source of information, and more than one way of explaining the subject. So here we go…

Compile-time string concatenation

We will start with a bug, taken from real life. It spans across three files:

#include <string>

struct Service
{
  static const std::string NAME;
};

#include "service.h"

const std::string Service::NAME = "SERVICE1";

#include "service.h"
#include <iostream>

const std::string MSG = "service " + Service::NAME + " ready";

int main()
{
  std::cout << MSG << std::endl;
}

Question: what happens when this program is executed?

Asserts in constexpr functions

Assertions (like C-style macro assert) are not an ideal, but still useful tool for indicating assumptions about program correctness, and help finding programmer bugs. In this post we will see how we can use assertions in constexpr functions. This works different in C++11 and C++14.

The GCC bug affects you

This is a follow-up to my previous post about a bug in GCC. I was reading comments, and observed that some readers say that the example I used is rare, or artificial, or that it does not follow “good programming practices”. I want to give you another example.