55: C++ Exceptions. Cannot Be Ignored.

Errors will happen. The question is how will you deal with them? The QA Friday from 2015 Dec-11 talked about this question. This episode explains C++ exceptions. C# also has exceptions. But C# is different enough to need its own episode. A good way to summarize exceptions is that they allow you to detect and error condition in one place in your code and make sure that the error will eventually get handled in some other place in your code. This allows you to focus on writing your code without stopping to check for errors after every method call. It also allows you to automatically clean up resources such as memory that needs to be freed or files that need to be closed. The technique for this relies on something called RAII which stands for “resource allocation is initialization.” Whenever you allocate some memory for example, instead of storing a pointer to that memory in a raw pointer, use a smart pointer such as std::shared_ptr which will take ownership of the pointer and make sure it gets deleted at the proper time when it’s no longer being used. Exceptions give your program an efficient and consistent way to handle errors even in cases where the alternatives are either unreliable or difficult to enforce. You can’t use exception everywhere though. If you call a web service or a method in a COM component or some other remote service that’s outside of your application process, then you’ll have to use error codes or some other mechanism to inform the calling code that an error happened. Listen to the full episode for more or you can also read the full transcript below. Transcript Exceptions are a really good way to deal with three types of errors: ◦ #1 are programmer errors. These have nothing to do with the user and could have been avoided with more robust code. ◦ #2 are user errors. These are caused by some action or input from the user. They could be accidental or on purpose. ◦ And #3 are resource and environment errors. These could be caused indirectly by the user or might just as likely be due to conditions beyond the user’s ability to control and beyond the ability of the application to detect ahead of time. The reason exceptions are a good choice for dealing with these errors is because they can happen at any time and without exceptions, you’ll need to deal with all of them for almost anything your program does. Now, you need to deal with exceptions too, but they make your code more robust and readable. Exceptions are not just for “exceptional” or “disaster”scenarios. They really just allow one part of your program to detect an error and then let some other part of your program handle that error. For example, let’s say that you need to allocate several different blocks of memory. Without exceptions, you would need to check each allocation request to make sure that the memory was available. You end up repeating a lot of error handling code each time you need to allocate memory. And this is just allocating memory. Need to open several files from the hard drive? You have to check each one to make sure it could be opened. And then when you want to read or write information from the file, you need to check the outcome of each of those actions as well for an error code. Maybe the hard drive just ran out of disk space after successfully writing several pieces of data. You never know when a failure will happen so you need to check for error codes again and again. This tends to turn your code into more error handling than actual code. And what do you do for constructors that have no return value? How can you return an error code when there’s no way to return anything? With exceptions however, you can write your code to focus on the happy scenarios and keep all the error handling separate. But there’s another benefit, one you can’t ignore. Let’s say that you call a method named find that returns some information you want to use.