Hacker News Reader

Comment by trws | Hacker News Reader

It depends a great deal on your situation. Where I work, we have codes up to 3 million lines, they all have exceptions and rtti turned on. You’ll find similar situations all over except at google and in gaming, and to some extent anywhere that last quartile latency is a serious concern. The thing about exceptions is that when you throw none of them they cost almost nothing, but throwing one costs on average about 1000 times as much as returning a value would. It’s a massive hit, especially if you care about latency, so it’s best to avoid them for control flow or anything but truly exceptional situations.

RTTI I’d say it’s best to only use in testing and debugging generally, it just plain isn’t reliable for the uses people seem to try to put it to.

View on HN

Okay, do you think the effort is worthwhile? Or do you think migrating to a language with a bigger runtime would have been a better choice? Because that is usually the conclusion I make. If you can afford that the compiler emits code for exception handling in all your functions and pay rtti then maybe your problem does not need that kind of performance in the first place. And you get all the downsides of using C++, and don't benefit from the upsides => just write it in go/java/c#

I think another big issue is the complexity overhead of 'introducing' exceptions in a already complicated language. When you use exceptions the control flow of the program gets 'invisible' should you recover from a exception.

Also, just writing data structures in general that obeys the weak and/or strong exception guarantee is not very easy [1].

Like it makes writing (correct) C++ even harder than it already is.

[1]: https://en.cppreference.com/w/cpp/language/exceptions

We need the performance, and are frequently at least testing if not running in production on bleeding edge hardware, which almost always supports c/c++ first. That doesn’t make it for everyone though, and honestly I normally tell people to avoid exceptions as much as possible. The big issue is that C++ as a language was designed with exceptions in mind. There is no other way to exit with failure from any constructor that the caller can deal with, so every non-exception class has to use a two-step setup to avoid throwing in the constructor. If you’re doing exception free for real, meaning you can still recover rather than turning them off and just letting the program abort whenever a throw would have occurred, it’s actually a much harder language to write for.

Don’t get me wrong, maintaining exception guarantees and ensuring exceptions are appropriately caught is terrible. I much prefer working with optional and outcome and similar personally, but the assumption of exceptions is very deeply baked in, and avoiding them safely is a lot harder than one might guess.

Also, remember that while exceptions cost code size, they cost literally nothing in instructions executed unless an exception is actually thrown. That’s why the common nix implementation is called “zero cost exceptions”. In the happy path case they are faster than returning a discriminant. It’s not having exceptions available that makes code slow, it’s using them for things that are expected rather than unexpected or for control flow.

The premise is that exceptions should be zero cost to check, however it worries me when profiles like Tim Sweeney says that his code got 15% faster by turning off exceptions [1].

[1]: https://twitter.com/TimSweeneyEpic/status/122307740466037145...

Reply on news.ycombinator.com