1. 6

  2. 7

    Allow me to summarise: If you make the exception into the common case, the result is awful.

    1. 2

      IMO it’s only worth using non-exception error handling in C++ if you have errors that are so common that they’re on the hot path.

      That “Expected” class they describe is useful, but if you’re using C++17 you’d implement it with std::variant.

      1. 1

        That surprised me. I thought I’d remembered that the difference is surprisingly small.

        It’s weird that the article doesn’t mention the compiler.

        1. 2

          It’s more a question of runtime and ABI than of compiler. If you compile to linux/ELF and your runtime uses libunwind there isn’t that much the compiler can do to affect the performance.

          Many compiler people talk as though that the performance of exceptions is the performance of code when no exception in thrown. Look at the phrasing about zero-cost exceptions, for example. (BTW, zero-cost exceptions either have a small cost or none, depending on how you count. It’s quite fascinating if you’re fascinated by that sort of thing.)

        2. 1

          Interesting results. I hope the author follows up by examining the results of turning off exceptions with compiler flags, of adding noexcept to functions, and the effect of bookkeeping done to report and handle exceptions.

          1. 1

            Reinventing algebraic types since 2012? ;)

            I’ve had a misfortune to work with code whose authors were so convinced exceptions are bad that they called functions from Boost’s ::detail namespace just to avoid functions that may possibly raise exceptions. Guess how much fun was it to make it work with newer Boost.