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

cppcon.org/
github.com/CppCon/CppCon2021
---
Writing code which successfully accomplishes a task is difficult. Four year software engineering degrees are, after all, spent learning something of substance. This difficulty only compounds as the code in question becomes less and less trivial. Successful accomplishment is not the only outcome of well written, real world software however: Tasks can fail for a variety of reasons.
From a certain point of view success is the least interesting outcome in software engineering. No one is woken up in the small hours of the morning because their software succeeded. Much gets said about the Ariane 5 but have you heard of the Ariane 4 or 6? It’s plausible that dealing with errors appropriately is the most important responsibility of a software engineer.
This talk will discuss errors and exceptions, how, when, and why they should be generated, how code should be structured to handle them, and what techniques can be used to ensure such situations are reported with sufficient context that the cause can be identified and addressed with minimal software engineer involvement.
---
Robert Leahy
Robert is a graduate of the University of Victoria where he specialized in graphics, gaming, and digital geometry processing. After 4.5 years in full stack web development he switched to financial infrastructure software development in early 2017. He’s since become involved in the ISO C++ committee while delivering high quality, process-driven code to meet the rigorous performance standards for which finance is so well known.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
*--*

[@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.

[@cw3dv]

wow nice talk!

[@Tobxon]

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

[@daver94]

Amazing 🎉

[@EduardoMengesMattje]

Great talk!

[@arthopacini1887]

awesome!

[@CppCon]

Thanks!

[@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.