Difference between revisions of "Intermediate C++ Game Programming Tutorial 22"

• • 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

• • 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).

• • 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

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

• • 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)

• • 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

• • 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, all objects in scope will be destroyed. 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

• • 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 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.

</code>

• Best practices 21:56