Intermediate C++ Game Programming Tutorial 22

In this video we learn how to use C++ exceptions to take our error handling to the next level. There is a lot of fear and ignorance surrounding exceptions among "C++ Programmers", and Chili's goal here is to elevate you guys above the shit-tier level to coders who can actually use this feature to its full extent. The second part of this tutorial will give concrete, practical examples of using exceptions in an actual game scenario.

Topics Covered

• Basic exception trying throwing and catching
• Exceptions 'bubbling up'
• Rethrowing with throw
• catch(...)
• std::exception and its derivatives
• Polymorphism in exception handling
• Exceptions and destructors
• noexcept and move constuctors vs. standard containers
• Throw by value, catch by const reference

Video Timestamp Index

Tutorial 22 Part 1

[Expand]

• Intro: exceptions are the main way of handling errors in C++ 0:10

• • Examples of its usage in the Framework, a good practice for working with any API
  • Everytime a Direct 3D Function is called, the return value is checked for error codes and handled

• Comparing error handling with and without exceptions 1:40

• • Conventional error handling requires checking function return errors for every function throughout the entire hierarchy of the code base
  • With exceptioins the advantages are:

  - you can catch an error anywhere in the code base (they "bubble up", or propagate up to a higher level function)

  - you can seperate your normal logic (code) from your error handling, without having to pollute your return values with error codes.

  - if you don't handle the error at some point, your program will be halted (uncaught exception).

• Example code to demonstrate try, throw, catch of a std::runtime_error("...") 3:53

• • The catch function is only executed if an exception has been thrown
  • Illustration of how exceptions can propagate out of functions
  • You can decide the level at which you want to catch an exception 6:04
  • Catch and rethrow 6:40
  • You can throw anything you want: an object, an Integer, string, pointer, etc.
  • You van overload the catch functions based on the type of information thrown

• Use catch(...) to catch any uncaught excepions 8:55

• • In this case, you don't get any exception object or value that you can output
  • Rethrowing still works

• Good practice: only throw exception objects that inherit from the std::exception class 9:51

• • STL offers a range of pre-defined exception objects, with two basic types that inherit from std::exception:

  - std::logic_error: due to faulty logic within the program

  - std::runtime_error: due to events beyond the scope of the program (such as file access errors)

• std::exception and its derivatives 10:49

• • The inherentance hierarchy of std::exception is very useful
  • The polymorphism lets you choose the level of detail in error handling, so that you can filter for specific errors
  • You can use parent types to catch general exceptions
  • An exception will be caught (/dispatched) to its most derived (most specific) type, when catch functions are overloaded for different types of exceptions
  • You can create your own error classes that inherit from the existing one for customized and finer-grained error handling

• Unwinding the stack: what happens to objects when throwing out of scope 13:39

• • If you throw an exception, the code is going to jump out of the current function to wherever it is being caught
  • Upon jumping out of scope, the destructors of all objects in scope will be called. This is called "unwinding the stack"
  • However, any objects created on the heap will not be destroyed, resulting in a memory leak
  • This is avoided by using unique (smart) pointers and allocate memory with std::make_unique<>() instead of using raw pointers and new
  • More generally, if you use RAII types (such as std::vector<>, std::string etc.), you will have no issues with memory leaks

• Exceptions and destructors 17:17

• • Never have destructors throw exceptioins, this will mess up execution ::bigly::
  • If you call any functions that can throw exceptions in a destructor, make sure you always catch them

• Move semantics and containers 18:34

• • Move operations don't work well if an exception is thrown
  • If a move constructor of a class can throw an exception, the STL classes will avoid it and default to the copy constructor
  • You can enable move operations in these cases by making the move constructor noexcept, which explicitly tells the compiler that there will be no exception thrown
  • Be mindful of when you mark your functions noexcept. You basically enter into a contract with whomever is using your code that the function will never throw exceptions. If you would ever want to change this, you risk nasty errors because the codebase may rely on your function being noexcept.

• Best practices 21:56

• • Always throw your exceptions by value and catch them by a constant reference
  • Never use exceptions as a form of flow control (jumping through your code), this is a terrible idea. Exceptions should only be thrown when something bad happens
  • Use exceptions for things that are out of your control as a programmer (think file / hardware access errors, network errors), otherwise use asserts
  • Asserts are for checking errors that you can avoid as a programmer, but you want to test for during development. Sanity checks. They should not be necessary when you ship a product.

Tutorial 22 Part 2

• Exceptions, applied in practice RPG Project Twin in the Chili Framework 0:10
  • A custom class ChiliException was defined (not recommended) that holds message, filename and line number information and virtual functions for information getters defined in derived classes
  • An inner class Graphics::Exception was defined that inherits from ChiliException and adds a data member of type HRESULT> (used in DirectX)
  • The Windows API doesn't use exceptions, so individual tests for every function using FAILED calls are used to throw exceptions. Macros such as CHILI_GFX_EXCEPTION() are used to generate the exceptions
  • In Main.cpp, Chili uses a try{ } inside another try{ }. The first is used to test if the creation of a MainWindow object succeeds, the second to throw exceptions using wnd.ShowMessageBox() of that MainWindow class
• The use of macros to generate exceptions 4:22
  • A macro CHILI_GFX_EXCEPTION() is implemented that expands to a constructor for Graphics::Exception(), that also takes two pre-processor defined macros (defined by the compiler):

  - _CRT_WIDE(__FILE__), for the filename

  - __LINE__, for the line number in the code

  • You need to use a macro for this to get the line number of each function call at the different throw points (instead of the line number of the function definition)
• The use of the HRESULT function 5:42
  • >HRESULT hr is used to perform a lookup DXGetErrosString(hr) of the error name string
• Working with streams (std::ifstream file and exceptions in the Sound class 7:05
  • For example: file reading to load sounds
  • Steams don't work with exceptions by default, you have to check the error flags to throw based on that
  • file.exceptions(std::ifstream::failbit | std::ifstream::badbit); turns on the excceptions for the failure and bad flags
• Recovering from an exception 9:33
  • For example: loading resources (like sound). By using a soft_fail flag, an empty sound gets added to the matrix of sounds so that the program can continue. In case of a hard fail the exception gets rethrown and stops the program.
  • Chili uses #ifndef NDEBUG throw e; #endif to always throw when in debug mode
• Recap of main take-aways 11:32
  • DO inherit from std::exception
  • DO use exceptions for errors that happan that are out of programmer's control
  • DO NOT use exceptions for sanity checks (use assert)
  • DO throw by value
  • DO catch by const ref&
  • DO use smart RAII types like smart pointers ALL THE TIME
  • DO NOT throw exceptions from a destructor
  • DO NOT throw exceptions from a move constructor if you want the move optimization in a std::vector etc.
  • DO mark functions as noexcept if you are confident that they will NEVER want to throw an exception, either now, or later on in development
  • DO not mark functions noexcept just because they happen not to throw right now - they might in the future so think carefully before going down the noexcept path

Extra Discussion

I had an interesting exchange with a viewer, and made a bit of a writeup here: essay time.

Source Code

• Sprite Github Repository (for Surface code)

See also

• Next in series (Tutorial 23)
• Intermediate C++ Game Programming Series