I wouldn't say "wrong", this is a subjective issue, and some people like them. It's just that exceptions can be dangerous, in a sense, because a very innocuous looking line of code or function call can end up executing something you don't expect, or your function can bail out before you expect. It's similar to how inheritance and virtual functions hide (encapsulate) what's going on, but also obscure execution too. Usually the encapsulation is good, but when you need to know exactly what's going on, they can throw wrenches at you. It can be really hard to figure out all the possible errors that could be thrown, or code paths that could be taken in any given case.

I don't know the specific reasons std lib was mentioned, that's a big topic. But generally in the context of a game engine, you need all custom memory management and I/O, so there isn't much place for std lib, depending on which std lib pieces and which platforms and which C++ you're talking about.

For exceptions: - A bit unpredictable (hard to optimize)

- Introduce a lot of exit points which are hard to find

- They deviate from the "pay what you use," since they generate some extra code

- They can introduce some nasty performance penalties (I experienced this myself a few yeas back, the compilers might be smarter these days, maybe)

About the stdlib: There's a "myth" that often times the stdlib/stl is slow and doesn't do what you expect (unless you've thoroughly read the documentation, which everyone should do anyway). I can't say I was personally affected by this since I also use C++ for nothing too serious. I said "myth" because the argument against the slowness it that this is an outdated notion.

Most C++ compilers these days should have zero cost exception handling, meaning that the non-exceptional path should be free. This works by making the compiler add exception handler data to the executable file, ie. telling where the catch() blocks are. When an exception is thrown, the stack trace is analyzed and the appropriate catch handler is found by searching for the return addresses in the exception handler data.

This can make C++ with exceptions faster than C with error checks because there's no branches to check for every error condition. Using __builtin_expect for marking the error conditions as unlikely may mitigate this issue.

The cost is that you have to ensure that all your code is exception safe unless you are extremely careful to ensure that exceptions are only thrown in places you've expected and coded for.

Exception safe code is both difficult to write correctly and often has a significant run time cost.

Agreed on both accounts but the grandparent comment was talking about runtime performance penalty, which is gone (for the non-exceptional path) in modern implementations.

But yes: exception safety, even basic safety (don't leak resources or crash) is difficult, let alone strong exception safety (no side effects if exception occurs).