03 - error reporting

Performance

Some functions which implement this error reporting mechanism return error number directly instead of writing to errno. This approach avoids mentioned performance problem but limits return type of the function to int. In rare cases, if only positive or only negative results are valid it's possible to fit both error number and the result into a single int - the calling code has to check the sign to interpret returned value properly.

Many mathematical functions from the standard library (e.g. std::pow, std::log) report errors by setting errno. Some projects (especially ones which heavily rely on such functions) which do not need strict compliance but need performance are compiled with -fno-math-errno (or -ffast-math which is a superset), effectively changing approach from errno to "garbage in, garbage out".

For more information see:

• https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

• SO: What does GCC's -ffast-math actually do?

• SO: Why doesn't GCC optimize a*a*a*a*a*a to (a*a*a) * (a*a*a)?

POSIX vs ISO

To clear out some confusion, as it often happens in this area, multiple things are in play here:

• ISO C standard

• ISO C++ standard

• POSIX standards

• practice and implementation, where a lot of Unix-like systems are not strictly POSIX-compliant

The C++ standard doesn't define the language entirely, for parts imported from C it refers to the C standard (newer C++ standards refer to newer C standards).

POSIX specifies portable operating system interface. This touches many aspects of an operating system, some are about system-provided C libraries and their interfaces. Some functions specified in POSIX are the same as in the C standard, so the implementation of the C standard library can be as simple as directly calling system functions. Because functions specified by POSIX heavily overlap with ISO C, they are often in one library that is shipped with the system.

A lot of work in this area has been done by the GNU project. Sometimes GNU makes decisions that are ISO and POSIX incompatible for practical reasons - this is mostly seen with system-level functions where GNU often implements slightly different interfaces. For more information, see SO: What does _GNU_SOURCE imply?.

What you should remember is that not everything you find in your system's C library is a part of C or C++. Some stuff is provided by the system and it's possible that some of the standard library headers expose system-specific or POSIX-specific headers for implementation reasons. So if you want to write "portable C or C++ program that does not require POSIX" check from where a given type of function comes from before using it. I'm writing this because I have seen and received (to review) many programs claimed to be multiplatform C or C++ that were actually relying on POSIX headers. POSIX is quite portable, but unlike ISO it is not on every operating system. Most GNU/Linux distributions are only partially POSIX-compliant.

Extra stuff

errno to text functions:

• https://en.cppreference.com/w/cpp/string/byte/strerror

• https://en.cppreference.com/w/cpp/io/c/perror

While errno is thread-local, functions which return textual representation aren't thread safe. An article elsewhere describes the problem in detail.

Care should be taken when mixing errno-based error reporting with bool return types:

• in case of errno, 0 means success

• in case of bool, true means success

Many function calls are put into if statements. errno (which has type int) with value 0 is converted to false. But the success for other kind of functions is represented by true. This creates a program with very surprising and confusing code: sometimes if (!func()) is correct to check against errors and sometimes if (func()).

summary

Errno is a global variable (1 per thread) that holds an integer representing error number. The list of predefined error numbers is specified (with varying precision) by both ISO and POSIX standards.

Generally, you should avoid using this mechanism. It delivers poor information, it is inefficient and ironically, it is quite error-prone.

If you face a standard library or 3rd party function which reports errors this way you have 2 options:

• stick to it for consistency (though I discourage "consistently bad approaches")

• translate it to a different mechanism (std::error_code is meant as a direct replacement)

Optional type

Optional is essentially a struct with an object of specified type and a bool indicating whether it actually exists. The actual implementation is much more complex (to avoid problems caused by types which always require initialization) but can be thought as such. It either contains or does not contain an object.

1
2
3
4
5
6
7
8
9
10
11
12
13

#include <optional>
#include <limits>

std::optional<int> safe_divide(int x, int y)
{
	if (y == 0)
		return std::nullopt; // return {}; works too

	if (x == std::numeric_limits<int>::min() && y == -1)
		return std::nullopt; // return {}; works too

	return x / y;
}

Non-empty optional can be initialized and assigned with objects of the matching type or types that are implicitly convertible to the destination type. Empty optional can be created with {} and std::nullopt.

1
2
3
4
5
6
7
8

// example calling code, somewhere else
std::optional<int> result = safe_divide(x, y);
if (result) // optional is convertible to bool, there is also .has_value()
	// result.value() - returns reference to T if present, otherwise throws an exception (safer)
	// *result        - returns reference to T if present, otherwise undefined behavior (faster)
	use_result(*result);
else
	// some error...

More examples and information on cppreference page about std::optional. You shouldn't have significant problems using it in your own code. Most of the operations are very intuitive and can be easily remembered by their name. If you do have problems, write down your questions and revisit them later once you reach classes and further chapters.

Compared to output parameters, there are multiple advantages:

• The code is much cleaner.

• It's impossible to read anything when empty.

• The function implementation does not have to return a special value in case of error, it simply creates an empty optional. No trouble with objects of types that have no special state.

The core disadvantage of the optional type is that it doesn't support holding any error information, only whether the value is present or not. For this reason it's discouraged to use optional in places where a rich state is needed in case of an error. In case of the example above it's fine because an empty result indicates that value could not be computed and very likely we will not care about the exact cause - we just know that many mathematical operations can not produce meaningful results.

Functional programming

As the name suggests, functional programming is all about functions. A common pattern is to encapsulate state and use higher-order functions (functions which accept other functions as arguments). With the help of monads, it's possible to write very consise code:

1
2
3
4
5
6

void run_simulation(double speed = 1.0);
std::optional<double> to_double(std::string_view sv);

// read config, convert string to double
// if convertion fails use value 1.0
run_simulation(to_double(config.speed).value_or(1.0));

As of writing this, boost::optional has significantly richer interface than std::optional, so if you would like to play with functional style of programming, I recommend to read boost's documentation (it's quite thorough) and use their implementation (this boost library is header-only).

Here is a more advanced example:

1
2
3
4
5
6
7
8
9

boost::optional<std::size_t> get_user_id(); // empty result if not logged
user_stats_t get_user_stats(std::size_t user_id);
std::chrono::seconds compute_active_time(const user_stats_t& stats);

auto time_active = get_user_id() // boost::optional<std::size_t>
	.map(get_user_stats) // boost::optional<std::size_t> => boost::optional<user_stats_t>
	.map(compute_active_time) // boost::optional<user_stats_t> => boost::optional<std::chrono::seconds>
	.value_or(std::chrono::seconds(0)); // boost::optional<std::chrono::seconds> => std::chrono::seconds
	// auto = std::chrono::seconds

This code hides a lot of if-else instructions inside. Various monadic functions apply different transformations:

• map:

  • changes optional<T> into optional<U>, requires a function of the form U f(T) or optional<U> f(T)

  • if there is a value, applies supplied function and returns its result as optional<U>

  • if there is no value, returns an empty optional of the destination type optional<U>

• flatmap:

  • like map, but the function has to have the form U f(optional<T>) or optional<U> f(optional<T>)$$$type<param_tmpl> func(type<param_tmpl>)

• value_or:

  • if there is a value, returns stored value

  • if there is no value, returns supplied argument

• value_or_eval:

  • if there is a value, returns stored value

  • if there is no value, returns value returned by supplied function (the function is only called if there is no value)

boost::optional allows to hold a reference type, std::optional does not. In this case I agree with the standard library approach: if you want an optional reference, just use a pointer. Additionally, optional references create some confusion when it comes to the assignment operator (boost documentation has examples on this problem).

An optimized version of an optional monad is available on https://github.com/akrzemi1/markable. This one does not hold a bool but instead reserves one value to have the special meaning, specified as a template parameter. This value can not be used normally - assigning it will make the object appear as empty.

Variant type

A variant type holds a value of one of specified types - e.g. std::variant<int, float> holds either an int or a float. There can be more than 2 types. std::variant allows even duplicates in types, though then using it becomes cumbersome as the primary value extraction mechanism (std::get<T>) becomes ambiguous and one must use index-based extraction instead (std::get<I>).

We could say that an optional is a specific case of a 2-type variant where the second type is void.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <system_error>
#include <variant>
#include <limits>

std::variant<int, std::errc> safe_divide(int x, int y)
{
	if (y == 0)
		return std::errc::invalid_argument;

	if (x == std::numeric_limits<int>::min() && y == -1)
		return std::errc::result_out_of_range;

	return x / y;
}

If you understand optional, you should have no problems understanding variant. There is no support for pattern matching or other syntax sugar for variants in C++ (at least at the time of writing this), so code that uses variants can become verbose:

1
2
3
4
5

std::variant<int, std::errc> result = safe_divide(x, y);
if (std::holds_alternative<int>(result))
	use_result(std::get<int>(result));
else
	std::cout << std::error_code(std::get<std::errc>(result)).message() << "\n";

Boost implementation here also has a richer interface but it requires much more knowledge to take full advantage of it so I don't present expert-level examples.

Why can not I use std::variant as an array?

Because it is not an array. std::variant has internal storage only for one element (size and alignment enough to hold one object of specified types). Adding array interface to std::variant is not even possible because for different indexes it would need to return objects of different types. Both std::get<T> (which takes a type as a template parameter) and std::get<I> (which takes an index as template parameter) are function templates and their return types change depending on provided template parameters.