The Death of Exceptions in C++

[00:00:00]For a long time, exceptions were the way to handle errors in C++. However, more and more developers have been moving away from them in favor of the expected class in C++ 23 and static assertions.

[00:00:11]Here are some of the biggest problems with exceptions. C++ exceptions often obscure control flow. This code looks linear, but in reality, it could exit here or here if an exception is thrown.

[00:00:21]Unlike some other languages, C++ function signatures don't declare which exceptions they may throw, which sometimes leaves the user guessing.

[00:00:29]There are scenarios where throwing an exception can be catastrophic. If you try to throw inside a destructor, it will terminate your program. This is because destructors are implicitly no except. If you try to throw inside a no except function, it will call terminate.

[00:00:43]Lastly, throwing exceptions can be absurdly expensive.

[00:00:46]Throwing an exception can be 100 to 1,000 times slower than a normal return.

[00:00:51]Expected is a C++ 23 vocabulary type, which is designed for explicit error handling. It represents a value that is either a successful result or an error.

[00:01:00]If the operation succeeds, it will contain a value of this type. If it fails, it will contain an error of this type. You can construct an expected object from a value of its value type, which is why this is allowed. You cannot construct an expected object from a value of its error type, however, which is why you need the unexpected helper.

[00:01:18]You can invoke the value method on an expected object to access its value.

[00:01:22]However, if it's holding an error, this will be undefined behavior. For this reason, you should check that your expected object has a value beforehand.

[00:01:29]You can also dereference your expected object to access its value.

[00:01:33]Or you can call value or, which will return its value if it has one, or return the value passed in if it doesn't. Expected has several monadic operations, of which transform is the simplest. It applies a function to the success value if it has one. As we can see, transform takes in a lambda, which takes in a parameter of the same type as our expected uh success value type. The transformation function can return a value of any type. This is the type returned by our invocation of transform.

[00:02:04]To demo more monadic operations, I changed our transformation function to return an int and it just performed a squaring operation. And then is another monadic operation, which is used when the next step in the chain can itself fail. And then takes in our doubled input and checks that it can be doubled again without overflowing. And if it can't, it returns an error. Or else is the counterpart to and then, which helps you handle the error case. Similarly, the lambda passed into or else must return an expected. Transform and and then only run if the expected has a value. Or else only runs if the expected has an error. Let's demo our code now.

[00:02:44]If this were production code, we may run into issues because squaring an integer can in fact overflow. So, we'd want to replace uh transform with uh and then.

[00:02:54]But, um because I wanted to go over all the monadic operations, I kept it here.