Exceptionally Bad: The Misuse of Exceptions in C++ & How to Do Better - Peter Muldoon - CppCon 2023

---

Exceptionally Bad: The Misuse of Exceptions in C++ & How to Do Better - Peter Muldoon - CppCon 2023

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 present the original intent/history of exceptions and a brief overview of how exception mechanics work and how they circumvent the usual stack return mechanism to set the stage. we will then examine the philosophy of using exceptions and then the many cases of exception misuse including resource management, retries, hierarchies, data passing and control flow to name but a few.
For each case, we will then suggest better ways to handle each specific situation. In many cases, exceptions are often dropped in favor of some other more appropriate paradigm.
Finally, we will introduce situations that can truly benefit from exceptions and 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 as a senior Engineering Lead. 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.
---

---

#cppcon #cppprogramming #cpp #exceptions

[origamibulldoser]

Bjarne is the man for "taking the stand" after this talk.

[dansanger]

If everybody is getting C++ exceptions wrong, which they apparently are, sometimes even in the standard library (throwing exceptions for parse errors or file errors ?!?!?!), then maybe the problem is with exceptions, not the users of the language.

[arisweedler]

Great talk. Entertaining and concise

I work on an exception-free code base, and we heavily use ADTs (algebraic data types: optional/expected/variant) to pass errors up the stack. This talk made me realize: we rarely have deep backtrackes, so we don’t really miss exceptions. But if we DID have deeper backtraces, maybe we would want them

[blaster_pro]

That was an anazing talk Peter, thanks dor that! Returning to c++ after a decade and having ro know those new tools/approaches is priceles!

[CppCon]

Congratulations Peter! Top third most watched recent tech talk of the week:

[jdkoftinoff]

I met lots of developers who say they don't use exceptions in c++ but since they don't compile their libc++ or libstdc++ with -fno-exceptions they actually are using exceptions but just don't handle them. This was a good talk. One reason however I like to not have main() or thread's do catch(...) is because an unhandled exception in my mind is a logic error and relying on ... to catch it means you forgot to handle it at the appropriate spot. So in this case you will instead get std::terminate() called which typically is abort() and you get a core dump and you can debug easily at the point of the throw instead of the point of the catch.

[fmatthew]

In one of my previous jobs. Adding a stacktrace to the systems base exception class was the single biggest productivity booster I added in one PR. Massive difference in debugging after that.

[kuhluhOG]

As the speaker said, exceptions should be used for rare cases, or as some people say "for the truly exceptional".
Here's a problem with that: Who determines what's "truly exceptional" or "rare"?
It depends on your problem domain.
And that also kinda means that if you want a general purpose library, that you can't really do that decision for anything but stuff which will (or should) never reach your users code.
Anything else can under their circumstances be something they expect to happen, something usual.
And since exceptions are expensive, if your decided to use them, you may make your library unusable for certain people because they would start hitting that exception often.

[emiliancioca]

Fantastic talk! Coming from the GameDev world, I have had little experience with exceptions but this talk made me much more confident in them. Looking forward to putting this into practice in some none-engine code :)

[NickDrian]

amazing content and well delivered. thanks!

[X_Baron]

I'd be interested in the details of and rationale behind the special stack unwinding, and what are the recent efforts to mitigate the costs.

[MarcEspie]

There are ways to deal with out-of-memory, specifically by having a preallocated pool you can free up for "disaster recovery" (which is usually enough to make sure your persistent files/databases are in a consistent system before dying a clean death).

[thelatestartosrs]

My only problem with std::expected<value, std::variant<errors...>>, having used it recently, is that you can't automatically compose `errors...`, I really wish we could declare functions like `std::expected<T::iterator> find(const T& collection, auto&& predicate) { ... return std::unexpected { };` This is the consequence of implementing stuff like expected, optional, variant at the library level and not the language level. Also, I do think it sucks that std::expected is defined as std::expected<T, E> and not std::expected<T, Es...> which would encapsulate the variant.

[gtdcoder]

29:03 This is still not sufficient. If connect(…) throws, notify will never be called. This try_connection function is not really an example of bad exception usage. It is an example of lack of cohesion. It should not decide when to call notify. It should just try calling connect a max number of times and provide the type of any error that occurs. There are 3 errors it should handle: Too many retries, connect returns false, and connect throws an exception. The exception can be caught within the function or allowed to propagate if documented sufficiently that the function might throw it.

[abit_gray]

My approach to exceptions is simple - Turn on debugger breaking when an exception is thrown. It you need to click it so much that it is annoying (which to some people can be just one exception), you should refactor the code to not hit that exception. Sometimes it is OK to have an exception but not always.
I know a lot of companies do not like exceptions as just use return value as an error code but I consider that to be only valid before C++11 ("Modern C++").

[thunderza]

first 7 minutes in and I am loving it.

[anatheistsopinion]

I'm definitely going to use the omega exception class.

[binary]

Ok, I’m going to take exception (pun intended) to the exceptional-variant visitor — that’s what polymorphic exception handlers are for, isn’t it?

[KX]

if I ever make a joke language, functions will only be able to return error codes, to return data you'd have to throw it.

[PaulMetalhero]

Is there any way to catch an OmegaException<T> ?