Exceptions in C++: Better Design Through Analysis of Real World Usage - Peter Muldoon - CppNow 2023

www.cppnow.org​
/ cppnow
---
Exceptions in C++: Better Design Through Analysis of Real World Usage - Peter Muldoon - CppNow 2023
Slides: github.com/boostcon
---
Exceptions were originally heralded as a new modern way to handle errors. However the C++ community is split as to whether exceptions are useful or should be banned outright. It has not helped the pro-exception lobby that, in their enthusiasm to embrace exceptions, a lot of code has been written that puts exceptions in a bad light.
In this talk, We will set the stage by presenting the original intent/ideals of exceptions and a brief overview of how exception mechanics work and how they circumvent the usual stack return mechanism. We will then examine many cases of exception misuse ( based on real world experience ), including resource management, retries, checking, hierarchies, logging, data passing and control flow to name a few. For each case of misuse, we will then suggest better ways to handle each situation. In many cases, exceptions are often dropped in favor of some other more appropriate paradigm.
Finally with the insight gained from the above, we will hone in on what the key attributes exceptions should provide, where they should be used and with this new viewpoint, introduce what a model exception class might look like.
---
Peter Muldoon
Pete Muldoon has been using C++ since 1991. Pete has worked in Ireland, England and the USA and is currently employed by Bloomberg. A consultant for over 20 years prior to joining Bloomberg, Peter has worked on a broad range of projects and code bases in a large number of companies both tech and finance. Such broad exposure has, over time, shown what works and what doesn't for large scale engineering projects. He's a proponent of applied engineering principles, elegant solutions and expressive code.
---
Video Sponsors: think-cell and Bloomberg Engineering
Audience Audio Sponsors: Innoplex and Maryland Research Institute
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
KZbin Channel Managed & Optimized By Digital Medium Ltd: events.digital-medium.co.uk
---
CppNow 2024
www.cppnow.org​
/ cppnow
---
#boost #cpp #exceptionhandling

[@jduck31337]

Thanks for the talk. I found it informative and entertaining. Hats off to Peter

[@Phroggster]

I try to watch a handful of programming language du jour talks every year, and I thought i was familiar with most of the names in the field for C++. This Peter Muldoon guy though, he's new to me, and he's got some style. Thanks for sharing this!

[@Yupppi]

People really wanted to tag along the presenter on having a speech :D this presentation had some fun personality to it. And I learned many things pretty clearly about error handling.

[@doBobro]

This gentleman has an exceptional taste.

[@jaredmulconry]

Having spent too long trying to collect my thoughts on exceptions, I agree with most every point raised. In spite of the obsession with std::exception and its derivatives, having been around for decades, their perceived value to most codebases is rarely realised. Throwing and catching gainfully can't be done without awareness of both ends of the equation. Generalised recovery from exceptional circumstances borders on oxymoronic. Tailoring towards rich logging is one possible direction, and I think you represented that perspective well. A proper recovery from an exception seems highly application-specific and context-specific, and I think you brought across that point really well.

[@alanwest6949]

😄 I was almost all ‘in’ on exceptions, eager to recover/continue without reporting, pass back state, or references to sessions, to be added to a retry list, save the user’s document to a recovery file. Because why catch if all you do is say “Caught!” and drop it on the floor? I read through the code of an implementation’s exception support. 😊 Wow it has to do all that? All that unwinding? All that state? All that searching? And some implementations generate a finite state machine to unwind faster? I see, now I would like exceptions to be zero cost if not used. And practically zero cost if used. 🤔 Can we delay the unwinding? Can I choose when the unwinding takes place? Can throwing simply…? 1. Push work on an exception queue, then jump and split/fork the stack at the earlier catch all? 2. Kernel maps in new stack pages whilst retaining the exception path’s pages. 3. Continuing in the catch all, I get to own the unwinding, to either pass it to a low priority worker thread, or for single threaded case, perform the unwind and free resources at a designated idle time. What am I missing? Edit: Just needs a thread local mini stack to push/pop instances of catch-all. A thread local mini stack to push/pop instances of unwind tasks. The catch-all owns the try block/lambda depending on how you see it. The catch-all may optionally look into specific exception types if it was written to, and re-throw. New instances of a catch-all inside a catch-all should work. The rethrow pushes an unwind task, pops off the catch-all and jumps to continue there? Just needs kernel support for saving the stack’s exception path memory pages, switching in a new page for the the stack to continue as before, like nothing is wrong. Just needs an unwind that can switch in a partial stack between throw to catch-all, to do the unwind? Just.. 😄

[@zenjasolaja9527]

Fantastic talk, well prepared and presented by Peter.

[@BoostCon]

Good to hear that you found this presentation to be of much value. Thank you!

[@kuhluhOG]

57:35 This little "Overloaded" template. I see this so often, be it in my or somebody else's code, that I am actually wondering myself, for why this isn't in the standard library. Especially std::visit basically begs for its existence, but everyone retypes (or copies) it all the time.

[@ProfessorWaltherKotz]

23:28 Wouldn't this be a nice feature request for compiler/profilers?

[@blacklion79]

logic error is a programmer's error which theoretically can be detected statically, but is not detected due to compiler technology limitations (such as API misuse), and runtime error is error in runtime environment which cannot be detected statically even in theory, like out of memory, file reading error, input data format error and so on. It is a very simple answer, I'm surprised nobody answered so.

[@christianoberdorfer459]

Thanks for this great and very helpful talk on exceptions!

[@BoostCon]

Thank you for your comment. Pleased that you found this presentation to be useful & interesting.

[@Danielm103]

Awesome talk!

[@about2mount]

How I handle Exceptions? struct ERROR_E { int exc_iine_number; int exc_type; string exc_inf; }; ERROR_E exc_e[100]; //Then at the very end of my programs I print the struct data into a log file.

[@vkrotevich6171]

I guess it's what should watch everyone after learning some basics of c++ . One of the greatest talk I ever seen.

[@johnmcleodvii]

Im going to disagree with memory exceptions never being useful. Ive written code where there was memory that could be freed without too much loss as it was the oldest item on the undo stack. I can also see its usefulness in discarding cached data, which can be recreated later at either computational expense or data transmission expense. This only works if the memory exception does not allocate memory and the location it is thrown does not corrupt the data.

[@kuhluhOG]

The (for me) most infuriating usages of exceptions are when somebody uses them for errors while parsing a something, or opening a file. Seriously, these are NOT the place where you want to use them...

[@blacklion79]

exceptions were in C++ long before the optional type, and return codes are worse.

[@dansanger5340]

Doug McElroy was right. Exceptions in C++ became a fiasco, with library writers throwing exceptions even for normal errors such as parsing errors and file IO errors. C++ should move away from exceptions and instead go for uniform error handling through return values, like many more modern languages are doing. "Exceptions only for exceptional circumstances" was never well defined and never will be. Seems like Doug recognized it as a smell from the very beginning.

[@karljenkins8416]

Nothing that hasn't been rehashed a million times over the past twenty years, but good for old times sake I guess :-(