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

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

[@jduck31337]

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

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

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

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

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

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

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

[@ProfessorWaltherKotz]

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

[@Danielm103]

Awesome talk!

[@oberdorc459]

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.

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

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

[@nisonatic]

Could a custom allocator be aware of freeable objects, though? That way you wouldn't have to abort that work.

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

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

[@karljenkins8416]

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