Sometimes things aren’t working. The user enters stuff in the wrong format, a file isn’t found, a network connection fails and the system runs out of memory. Those are errors and they need to be handling.

In a high-level function this is relatively easy. You know exactly why something was wrong and can handle it in the right way. But for low-level functions this isn’t quite as easy. They don’t know what was wrong, they only know that something was wrong and need to report it to their caller.

In C++ there are two main strategies: error return codes and exceptions. The “modern”, mainstream C++ way of handling errors are exceptions. But some people cannot use/think they cannot use/don’t want exceptions - for whatever reason.

This blog post isn’t going to pick a side on the fight. Instead I am describing techniques that make both sides - relatively - happy. Those techniques are especially useful if you are developing libraries.

A little over a month ago, I’ve released the first prototype of standardese. Now, it has finally reached version 0.1 - it took way longer than I thought.

Well, it always takes longer as the estimate.

It doesn’t bring many more features on first look, but massive parsing improvements.

In the previous post I’ve discussed the C++11 final keyword and how it can be used. I also gave a guideline that you shouldn’t use final on non-polymorphic classes. My reasoning was as follows:

1. For some classes - like policy classes or any other class where you might want to have the EBO - making them final can be harmful.

2. For other classes - those which aren’t used polymorphically - final is unnecessary. Every (good) C++ developer is taught early on that you shouldn’t use a class in a polymorphic inheritance hierarchy if it doesn’t have any virtual functions. Public inheritance there makes no sense and is harmful. Everybody knows that, the final is just there to enforce it.

3. There are only little use cases for final in polymorphic hierarchies. So in general you don’t need it.

This has spawned a discussion both on reddit and in the blog comments, so I decided to write this follow-up to unify the discussion and write about each argument.

C++11 introduced the final “keyword”. It can be used to mark member functions and classes as final, meaning that they cannot be overridden in derived classes/be base classes.

In this post I’ll take a closer look and explain why I consider the use of final classes problematic in some cases.

A few weeks ago I tweeted the following:

I was requested to give a review about it:

This is basically the workflow I’m doing for issue driven development.