Exhaustive switch statements are switch statements that do not have the default case because all possible values of the type in question have been covered by one of the switch cases. Exhaustive switch statements are a perfect match when working with scoped enum types. This can be illustrated by the following code:
| #include <iostream> | |
| #include <string> | |
| enum class Color { | |
| Red, | |
| Green, | |
| Blue, | |
| }; | |
| std::string getColorName(Color c) { | |
| switch(c) { | |
| case Color::Red: return "red"; | |
| case Color::Green: return "green"; | |
| case Color::Blue: return "blue"; | |
| } | |
| } | |
| int main() { | |
| std::cout << "Color: " << getColorName(Color::Green) << std::endl; | |
| return 0; | |
| } |
Now, if a new enum member is added:
| enum class Color { | |
| Red, | |
| Green, | |
| Blue, | |
| Yellow, | |
| }; |
the compiler will show warnings pointing to all the places that need to be fixed:
| enum.cpp:12:12: warning: enumeration value 'Yellow' not handled in switch [-Wswitch] | |
| switch(c) { | |
| ^ | |
| enum.cpp:12:12: note: add missing switch cases | |
| switch(c) { | |
| ^ | |
| enum.cpp:17:1: warning: non-void function does not return a value in all control paths [-Wreturn-type] |
If you configure warnings as errors, which you should do if you can, you will have to address all these errors to successfully compile your program.
Without the exhaustive switch, the compiler would happily compile the program after adding the new enum member because it would be handled by the default case. Even if the default case was coded to throw an exception to help detect unhandled enum members, this exception would only be thrown at runtime which could be too late to prevent failures. In a bigger system or application there could be many switch statements like this and without the help from the compiler it can be hard to find and test all of them. To sum up – exhaustive switch statements help quickly find usages that need to be looked at and fixed before the code can ship.
So far so good, but there is a problem – C++ allows this:
| Color color = static_cast<Color>(42); |
Believe it or not, this is valid C++ as long as the value being cast is within the range of the underlying enum type. If you flow an enum value created this way through the exhaustive switch it won’t match any of the switch cases and since there is no default case the behavior is undefined.
The right thing to do is to always use enums instead of mixing integers and enums which ultimately is the reason to cast. Unfortunately, this isn’t always possible. If you receive values from users or external systems, they would typically be integer numbers that you may need to convert to an enum in your system or library and the way to do this in C++ is static casting.
Because you can never trust values received from external systems, you need to convert them in a safe way. This is where the exhaustive switch statement can be extremely useful as it allows to write a conversion function like this:
| Color convertToColor(int c) { | |
| auto color = static_cast<Color>(c); | |
| switch(color) { | |
| case Color::Red: | |
| case Color::Green: | |
| case Color::Blue: | |
| return color; | |
| } | |
| throw std::runtime_error("Invalid color"); | |
| } |
If a new enum member is added, the compiler will fail to compile the convertToColor function (or at least will show warnings), so you know you need to update it. For enum values outside of the defined set of members the convertToColor throws an exception. If you use a safe conversion like this immediately after receiving the value, you will prevent unexpected values from entering your system. You will also have a single place where you can detect invalid values and reject and log incorrect invocations.
Code, the Universe and Everything... 