Failing Successfully: Reporting and Handling Errors - Robert Leahy - CppCon 2021

[@robertleahy6923]

Speaker here: It's been pointed out to me that I (along with my test audiences!) managed to miss the fact that std::from_chars does not ignore leading whitespace (unlike the other integer parsing functions mentioned). This doesn't affect the substance of the talk but I don't want anyone to add unnecessary logic to try and detect leading whitespace because of an erroneous remark in a talk on error handling.

[@Dth091]

I'm glad you handled the error you made in your talk so well, and reported it clearly to us :)

[@KulaGGin]

Great talk, thanks for that. Your patterns to structure code go right next to Uncle Bob's Clean Code suggestions in my notes, in the SRP/SoC section. I was thinking how could I actually separate logging from the component, and it's events and Observer, you're right, of course!

[@fdwr]

Thank you for the talk - many head nodding moments. 19:30 The zoo of error-ish things introduce in C++11 has been royally confusing to me due to naming. Error code is not actually an error code, but contains an actual error code plus a helper error domain interface. Then you have the subtle distinction between error_code and error_condition which are mostly identical in their interface, yet don't inherit from a shared base class for generality :/ ... std::errc - an error code std::error_code - a different error code? std::error_condition - yet another kind of error code 🤔 std::error_category - a utility helper interface for error codes 😵 ...I had to make a mental map just to sort them all out: std::errc -> std::posix_error_code std::error_code -> std::platform_dependent_error std::error_condition -> std::platform_independent_error std::error_category -> std::error_domain/utility/mapper std::system_category -> std::platform_dependent_error_domain std::generic_category -> std::platform_independent_error_domain std::future_errc -> std::future_error_code std::future_category -> std::future_error_domain std::io_errc -> std::iostream_error_code std::iostream_category -> std::iostream_error_domain.

[@tcroyce8128]

This year we are seeing really great topics that can be enjoyed by even the beginners.👌

[@ophi47]

I can't believe no has commented how great this concept is. I know it can grind some gears lol.

[@Tobxon]

I like they we he is talking somehow. It gives my brain the feeling of listening to drama (positivly meant).

[@cw3dv]

wow nice talk!

[@arthopacini]

awesome!

[@CppCon]

Thanks!

[@EduardoMengesMattje]

Great talk!

[@daver94]

Amazing 🎉

[@erichlf]

@7:55 "there are far more strings than integers." This is untrue, they are both countably infinite and therefore there are the same number of strings as integers. The idea that there are strings that aren't numbers doesn't mean there are more strings than numbers. I know this is very counter intuitive, but so is the idea that there are the same number of of numbers between 0 and 1 as there are on the entire number line. Both are uncountably infinit in this case.

[@erichlf]

In the case of the types then this is true, which is what the point was really.

[@louism11]

Not in a program in a language where integers are a fixed number of bytes. He was comparing the input string of atoi() with its return value, not pure mathematical integers.

[@masheroz]

There are more strings than ints.

[@iceman8075]

also did you forget that some infinities are larger than other infinities? infinity + 1 > infinity, the former infinity is larger than previous.

[@pauldubois0]

You want to make claims regarding unbounded analogues to C++ types? Then, for every Real, I claim there's at least one String that represents it. Therefore Strings are uncountable.