In the past, books stated that exception handling was slow for C++ and game dev. The books suggested to call std::nothrow when allocating memory, for example, and then using an if condition to see if the pointer is null or not. These days, I'm not sure. My assumption is it's fast these days. Has there been a best practice for using exception handling these days for games?

Interesting. I guess I'll continue to avoid them then unless it's necessary. Thanks for the thoughts.

Since C++11 functions not throwing exceptions and marked as such (noexcept) should run with no penalties.

but I pretend that they don't exist in C++

Interesting. I'm so far from the console world...

So I suppose you never use STL neither on consoles ? You might also avoid to use references (ie a dynamic_cast that fails on a reference should throw an exception). Or do you still disable exceptions with a compiler flag ? That can also be annoying when using middlewares...

I'm not really sure if dropping support for exceptions in current era is good idea.

Exceptions make code cleaner(for ex. you don't need to pass error code via method return codes or arguments), but they need to be used in exceptional situations(a lot of people abuse use of exceptions and try to hide some high level logic inside of catch block).

About performance, in x64 you don't pay any cost when calling function that may throw, all the cost is moved in case when function actually throws and you need to handle exceptions. But as i said, this should occur in exceptional situations(ex. missing file that should be there, problem with connection etc) and mostly at this time you don't care about performance.

I can't speak about consoles(i've never worked on one), but i bet their differ between architectures, as well in x86 land you pay small cost for every function call as compiler generates code for stack unwinding.

In the 10 years I've been in the industry, exceptions have been disabled on every single C++ project. Legacy code didn't use them, library code doesn't use them, game engines don't use them, C libraries can't use them, and most programmers in the industry don't know them well enough to make good use of them anyway.

The implementation of exceptions in C++ has never been particularly good anyway, not just in terms of performance but also in terms of the hoops you have to jump through to make your code fully exception-safe, so this hasn't been as much of a loss as people might think.

Thank you for the details.

I'll start to deviate a bit from the original topic...

Has anyone here heard about ISO C++ SG14 ? This is the study group from the C++ ISO standard which is studying how C++ could be improved for the game industry (among several others).

Here are some links in case you might be interested:

https://isocpp.org/blog/tag/sg14

https://groups.google.com/a/isocpp.org/forum/#!forum/sg14

What do people here think about this ? Do you think works like this might imply enough changes in the console hardware, or in the C++ mechanisms to allow such 'broken' things in gaming in a near/far future ?

To the extent where they fix things we already use, then yes. For example, most engines roll their own RTTI. If standard RTTI becomes just as effective and efficient, then I can see engines moving over to use that.

To the extent where they fix things we learned to work around or live without, such as exceptions, then no. I don't think anyone is going to retrofit exceptions into existing engines.

You'll find that almost all C++ game middleware will avoid exceptions too

Sorry, I couldn't resist :)

But on a more serious note, to the OP: exception handling is not inherently bad, or slow. Exceptions on consoles suck because they use shitty 10-12 year old compilers. Exceptions under Win32 are slow if you don't use the Microsoft compiler because SEH Exceptions for 32-bit Windows are patented (so the other compilers default to using setjump/longjump which is insane).

Exception handling under Win64 is (almost) zero overhead execution-time wise (not binary size wise, unluckily) unless you actually throw. Go ahead and time it, if calling a non-optimized-out small function some million times takes, say, 4.53 +/- 0.01 seconds, then calling the same function with exception handling will take 4.53+/- 0.01 seconds. Only if you actually throw, things look different. But throwing is an exceptional thing, so that is alright.

More important than the fact that exceptions are slow (they are not) is the fact that it is impossible to predict how long the handling will take. It can be anywhere from a dozen cycles to milliseconds (if, for example, a destructor flushes and closes files). Depending on the situation, and in particular depending on your realtime-requirements, this uncertainity may be the one thing that makes them forbidding.