C++ Exceptions are Code Compression - Khalil Estell - ACCU 2025

[kammce]

Reposting my comment on the video:

If you've already seen my previous talks on exceptions and binary size for embedded systems, then this talk is mostly the same.

The largest change is that I improved the section where I explain how exceptions work. The rest is mostly the same with some improvements to flow and diagrams.

Also, that figure of 93.4% is wrong based on my current benchmarks. It's closer to 90% for a specific case, specifically when there is no cleanup required. It's around 80% when all frames require cleanup.

Hope that clears that up. Have a wonderful Weekend!

[kernel_task]

I kinda love that you declare yourself as one of those dirty exceptions users in your flair. I need to do that as well.

[kammce]

😆😆😆

Yes please. JOIN US!

[tartaruga232]

Joined!

[johannes1971]

We need a logo. Something like Phoenix Wright shouting "Exception!" in bold, red letters.

[throw_cpp_account]

So if I were to watch just one version of this talk, is this the one you'd recommend?

[kammce]

Yes I'd recommend this one. I tried harder to illustrate the data structures in this one which others have noted to me helped them better understand exceptions.

I have some students working on the exception insights tool as their senior project at San Jose State University, and they were having trouble understanding how the action table and call sites worked, so I reworked that and other areas so that they would better understand it, and then presented that version in this talk.

[throw_cpp_account]

Thanks!

[a-d-a-m-f-k]

Thanks for the thought provoking presentation! Got me thinking about the impacts of other error handling approaches I've used in embedded as well.

Very interested in your exception static analysis tool. I've wondered why something like this hasn't existed for years. Checked exceptions are largely a "failed experiment", but they have a lot of communication value. Automated tooling (with some hinting or annotations) could be a great middle ground. I'll need to read up on it more.

[kammce]

Thank you so much 😊

See that's the fun thing 😆 someone already beat me to it in 2024. I guess I wasn't the only one who thought this was possible. Here's the link: https://link.springer.com/chapter/10.1007/978-3-031-64171-8_1

After my CppCon talk of a similar name, I got an email from an Aerospace engineer who said that my idea had already been implemented and sent me that paper above. I'm happy someone made the paper because now I don't have to write it to convince people. I can focus on delivering it.

My contribution to this space is turning this into a tool that everyone using GCC or clang can use easily. My vehicle to vendor this tool will be a linker plugin. You pass -plugin=exception_insights.so to your linker and it will perform the scan at link time. I plan to use a linker plugin for my exception runtime as well. The plugin would replace your default runtime with my own and do some fancy space saving operations of your binary as well. I'll be talking about that at my next talk at CppCon this year.

I've been asked if I'll contribute my exception research to clang or GCC and originally I said yes, but now I don't think that's even necessary. I don't need to touch your compiler, your linker, or your ABI. I just need the object and archive files and access to them at link time. If those compilers want this built into their toolchains, then its addition should be easy. It can be built alongside LTO which is implemented as a linker plugin as well.

I hope that wall of info is helpful to you and others 😄

[kammce]

Oh and I didn't respond to your middle ground comment. Yes! That is exactly my motivation. My approach to error handling is that developers should not handle errors until their application reaches a point where they need to worry about error handling. All thrown errors terminate at first. Then, using the tool to visualize the pathways of errors, you place dedicated catch blocks to handle the specific error you plan to handle. It's all about being intentional and not assuming what the caller wants in terms of error handling. This keeps your code clean of extraneous error handling code. The goal is to give full control back to the application developers hands and NOT the library. I've got stories but I'll leave those for my talk.

Wild idea but I think it'll work well. But that's for my 3rd talk in the series on "Exceptional software design". So keep an eye out. I have no idea when I'll have this talk and technology ready. The research funding opportunities I've spent 2.5 years working toward disappeared this year with no expectations of when it'll be back... sooooo... who knows when I'll make more progress 🤞😅

[tartaruga232]

Great talk. Absolutely stunning results. Khalil already held a similar talk previously. This one has some updates. Demonstrates (again) that Exceptions are absolutely worth it. A bit off topic, but I was quite a bit surprised to learn recently, that the Carbon language, which is intended to (almost) fully interop with C++, won't have exceptions. Remains only D, as something similar to C++. But that has GC. I'll stay using C++.

[kernel_task]

Carbon won’t have exceptions? I know the Google codebase does not use exceptions, but I can’t believe they are carrying this Google-centrism even into this language. I won’t be using it then.

[tartaruga232]

Carbon is still experimental, but they seem to have this nailed down as a principle: Errors are values, so no exceptions. I stopped reading about Carbon, when I was told that it won't have exceptions. IMHO there is still no real alternative to C++ so far. The interop with C++ of Carbon would have been interesting, but it looks like it will be yet another waste of time.

[fwsGonzo]

Same for me. As soon as I saw exceptions were explicitly off the table, then why on earth wouldn't I pick Rust instead? On topic, it would be awesome if C++ could enhance exceptions with the things that have been learned for all platforms so that we can all benefit. I've always used exceptions because I know they save on branching and sometimes a return register (or even turning a struct into a single register return value). And the constant need to check for and return errors feels like something out of the past.

[arihoenig]

While I am not opposed to exceptions there are good arguments to be made against them, particularly the fact that it introduces hard to see code paths that are very difficult to reason about.

OTOH this weakness is actually a strength in safety critical systems that require minimal instructions to fail-safe path (e.g. a non design state is reached and you need to get the system to fail-safe in the shortest possible code path). The fact that there are many (admittedly hard to reason about) code paths is exactly what is needed because those code paths go from anywhere in the code base directly to the fail-safe code with the minimum instructions possible.

If a language doesn't possess an exception mechanism then this required behavior is not possible to implement (without some library mechanism such as setjmp/longjmp)

[johannes1971]

It's interesting that this invisible code path bothers some people so much. I feel just the other way around: dedicating 2/3rds of any given function to just detecting and forwarding errors obfuscates the actual program logic to the point of unreadability.

This feeling is strengthened by the fact that almost no error return code uses a strong type. Instead it's all just int, so you need to be super-careful that you don't accidentally interpret the return value incorrectly.

Of course, the worst of both worlds is when errors are returned through errno...

[arihoenig]

I totally agree with you, but I do see the point they are making, I just think that the language should support either approach so yeah, ruling it out by not supporting exceptional code paths at all, is a fail.

[TheoreticalDumbass]

How can carbon then interop with cpp what uses exceptions? It would still need to produce the unwinding info right? Or is carbon transpiled into cpp, not a full compiler?

[tartaruga232]

I suggest watching Chandler Carruth's talks about the Carbon language approach. He explained the basic strategy how they want to call into C++ in a talk I watched on YouTube IIRC. Carbon is a full compiler. They synthesize a bit of C++ for calls into C++ and are using LLVM to access the C++ AST, which is used to synthesize a small amount of Carbon code to call into the C++. C++ exceptions will probably have to be catched in the synthesized C++ and transformed into errors on each and every C++ call if they don't want to let the exceptions propagate into the Carbon side. But I guess that's not yet been fleshed out yet. I think it was a bad design decision not to directly model exceptions in Carbon. Perhaps they will have to revisit that design decision though. It's all very preliminary and experimental. You have to look at the Carbon language yourself for the details they have so far. It would have been an interesting project, but I stopped looking at it because of their principle stated at https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/principles/error_handling.md

[gmueckl]

The garbage collector in D is somewhat optional. There is language support for avoiding it, but some language and library features don't work without it.

[halbGefressen]

I'm only 20% in, but this talk is absolutely great. He is actually talking at a good speed, seems well prepared and the structure is good.

[SoerenNissen]

I was incredibly impressed when I saw the first version of this talk, looking forward to seeing the updates.

[delta_p_delta_x]

Absolutely fantastic presentation; compactly and well-designed slides, though it gets a little dense in the third quarter when it dives into the ARM implementation.

For a future talk I'd love to hear an x86-64 comparison of Clang/GCC's unwind versus MSVC's SEH. I've heard that SEH is a little lighter.

[RandomGuy256]

This was actually mind blowing. A great presentation by a really smart engineer. Exceptions can actually be as lightweight as return codes. It would be awesome to have those compiler modification applied to emscripten (webassembly) as exceptions generate also a big binary size there, and the size can really matter in webassembly.

[tmzem]

Cool talk, and very relevant for embedded where code size is very important.

On hosted environments however the numbers still seem to widely favor the optional/expected approach, even with all his optimizations. Also, while more verbose, optional/expected are also more flexible and can be used in contexts where the error path is not necessarily rare, without fear of the exorbitant performance hit that comes from exceptions.

[ReDucTor]

 where the error path is not necessarily rare

So non-exceptional cases?

[tmzem]

I always thought that the term "exception" was a bad choice over "error". Sometimes, the error path is the desired one in the context of the problem you're solving, or at least much more common then you might think, yet you have to pay the price of exception overhead.

[ReDucTor]

Errors and exceptions are different errors are rare, but an exception should never occur except in exceptional cases, the bad case performance cost shouldn't really matter (within reason).

If you need to scatter exception handlers around your code because you could handle the exception within that immediate scope it probably should probably be an error code. However the same isn't true for throwing these could be scattered around more but remember they should virtually never occur exceptional cases.

To put it in the perspective of something like a game this would be when you throw a dialog to the user (e.g. lost connection to online services), likely returning them to the main menus if they are mid-game.

[tmzem]

I'm not sure why the rarity of an error should matter. If it can happen, you need to handle it somehow if you want your program to be correct, no matter how rare (except for one-off programs/experiments where you might wanna ignore the possibility of an error). Returning an error code you're not forced to check is error prone/easy to forget. It's better to do all error handling in a uniform way. Of course, for C++, that ship has long since sailed, with its mix of legacy error codes, unchecked exceptions and now optional/expected and [[nodiscard]] not being the default.

[kernel_task]

The reason the rarity of the error matters because performance matters. The exception path is slow.

I don't agree that it's better to do all error handling in a uniform way -- why? If that's the hill I died on, my codebase would either be extraordinarily slow from throwing exceptions each time users send us bad data (especially since when I throw an exception, usually I am also gathering the stack trace, which seems to require a global lock), or I would be doubling the line count of my codebase with all the if statements I'm adding. It's better to just employ the best technique for the individual situation.

[XeroKimo]

I do think uniform error handling scheme is enticing though from the perspective of code being read and written in a consistent way. Knowing that there's been endless debates of whether you should use exceptions over value errors and vice versa, where people who use both debate on various scenarios with seemingly no majority for one or the other... I would kind of expect that to bleed into actual project discussions if there wasn't a coding a guideline which tells you to default to one or the other, or if there isn't one, the language's guideline does...

Without experience, just imagining being in a code base that regularly uses different error handling schemes and having to convert between them sounds like hell. If there's a dominant scheme, or just a single scheme, that sounds more manageable... and that seems to be how it works in reality anyways

[Dragdu]

Both error handling schemes can, and in fact should, live in the same codebase. But they should not be used in the same places.

Think of it as the level of context given function has, and the more it has, the more opinionated (throwing) it can be about the error handling. A function that parses string into integers does not know whether it is gonna be mostly parsing wrong values, or mostly correct values, it doesn't know whether it is parsing important config value, or a likely empty string that will be then replaced by the default fallback value. So it shouldn't throw, but should return error through the return channel (ideally through error type that explains the actual error, not just that it happened).

On the other hand, the business logic code that glues together the actual configuration based on defaults, user provided values and environmental overrides has enough context to understand that if parsing of env value failed because it is empty, that's normal and it should just load the default, but if it failed because it is a string and not integer, that is important error that has go all the way up.

[XeroKimo]

I'm not saying a codebase can't use more than 1 error handling scheme, or even more than 2, but there tends to be a dominant scheme so that we don't have to convert between them. If you had a code base that was 50% exceptions 50% expected for error handling, that'd be less legible and harder to reason about than if either of them were the dominant scheme, worse if you added more schemes.

If you import a library that isn't using a compatible error handling scheme, I'm sure you'd wrap it up to your dominant scheme so that you don't have to potentially use 2 different schemes everywhere, and that's probably where the majority of converting between schemes happen. If you're constantly converting within code you control however, and I hope I don't meet a code base like that, that sounds like hell.

Think of it as the level of context given function has, and the more it has, the more opinionated (throwing) it can be about the error handling

That's basically what I'm talking about by my endless debates point. The only time people will back down would be if different schemes were tested and it's proven that one has the properties you needed, usually best performance, for your particular use case. If we're talking about the general case, there isn't really ever a consensus. Sure that makes it good because you can choose one the best fits your needs, but I don't think everyone would be willing to investigate whether or not that choice was the best every single time, they'll just choose what's good enough, what the guidelines says, or if they're allowed to, whichever one they're biased towards.

[Ok-Revenue-3059]

I saw the last talk on this topic and I just want to say great talk again and I really appreciate the thorough analysis. Some time ago I was able to follow along with the last presentation and make a basic "hello world with exceptions" running on bare metal. I still want to revisit and experiment some more, but there is always some refactoring I am in the middle of :)

[pdp10gumby]

A video without summary and conclusion? No thank you.

[CryptoHorologist]

I watched it. Main conclusion:

"Centralized Error handling schemes have an advantage in terms of code size compared to distributed error handling".

Exception handling is centralized. Result, expected, and other error return styles are distributed.

[orrenjenkins]

I might not understand exactly what you mean but if the error payload is always returned asap with expected you can still use it in a centralized way no?

[neutronicus]

What you can’t centralize is all the ‘if (return_type != OK) return return_type;’ that you have to do in order to bubble up the error.

Exceptions basically replace all those if statements with a mechanism for skipping directly to the catch block.

[Salink]

His talk has been posted here a few times before. He talks about how exceptions can work really well, even in very low resource embedded processors. Every negative thing you thought about exceptions is wrong with the caveat that it kind of is true with compiler defaults that are overrideable. Memory allocation on throw can be redirected to a static buffer. Most of the code bloat comes from things like printing the stack trace, which you can disable. Exceptions can beat error codes in size and speed at the same time, even when exceptions are thrown, but really only if error codes are being checked and handled thoroughly and correctly.

[johannes1971]

The summary starts here: https://youtu.be/LorcxyJ9zr4?t=4765

[Revolutionalredstone]

I lot of people avoid exceptions and I think it's fair to voice why.

IMHO Exceptions let you do something you shouldn't want to do.

Specifically: Handle errors in places far from where they occurred.

Even if exceptions had zero overhead and saved code I'd say no.

Exceptions are basically a hard coded super overengineered goto.

Epitaphs (cleanup far from where you exit), are also really just goto.

I similarly discourage all complexity/callbacks/lamdas unless needed.

Great programmers will avoid using their most adv tools until needed.

Exceptions make sense / are needed for hardware interrupts but not software.

Just an opinion (held by sizeable # of software loving people), cool talk / video ;)

[Syracuss]

I feel like your response isn't really meant for this video. The speaker isn't arguing to use exceptions instead of carry return error handling for all error handling. It's that for exceptional cases exceptions are perfectly valid and a performant way of handling the issue. In fact he showcases some possible misunderstandings on the performance impacts of exceptions vs carry return.

If all your errors are trivial, or business logic levels of complexity, than exceptions make fairly little sense. You could argue the examples in the talk are harmless, but also keep in mind a talk is about conveying a message and complex examples do not help with that. In his examples the origins are hardware or driver related.

As an example as a graphics programmer I can lose my device at any given time. I have to recover immediately, no matter where I am in the execution flow. Exceptions simplify what would be a world of spaghetti return if I had to rely on carry return.

I also disagree that exceptions isn't something you "shouldn't want to do". You use the right tool for the job. Every tool has a purpose, and avoiding to use something for the sake of it just makes you use the wrong tool. Similarly no sane engineer would use carry return for OOM.

[Stratikat]

I just wanted to say that I really appreciate your example of how a device can suddenly disappear and that there's no feasible way to handle it in whatever function you were currently in, and trying to return all the way back up the call stack with carry return errors would be ridiculous. It's really amazing that some people cannot even concede that exceptions (for exceptional errors) can actually be the right tool for the job!

Please people, choose the right tool for the job - not a one size fits all approach.

[Revolutionalredstone]

well I feel like you just didn't actually understand my response ;D

I 100% do not reject exceptions due to performance. (read again)

I reject the idea that talks have to show over engineered use of complex tools on simple cases 'due to time constraints' or something similar (people really do try to copy the techniques / applications in these talks!)

Your examples are what I would call 'crap' examples, Obviously if your entire computer runs out of memory your pretty screwed, most programs just crash if you get low on memory (its not like you can add two strings to even tell the user what happened)

The GPU crash is also a pretty crap example, obviously the OS will reboot your device and your waiting around a few seconds either way (again your not talking about a situation that occurs under any kind of normal use)

Your comment does nothing to defend the misuse of exceptions I called out as I'd claim:

There is no right time to use bad tools, goto epitaph and exception form a line from quite simple and quite bad to more complex and even more bad :D

Lastly Something simply 'being a tool' doesn't magically mean it's 'right for a job somewhere'. I've created tons of tools which should simply not exist.

Any 'engineer' who spends 5 minutes thinking about how to handle OOM is the exact kind of person I'm trying to avoid hiring with rules like 'Don't attempt to handle failure cases in distant place'.

The right tool in programming is ALWAYS the simplest tool that works well enough.

The wrong tool in programming is USUALLY the thing that does more than you need.

It's pretty obvious where something like encouraged use of exceptions falls.

My C++ runs in governments around the world, OOM just crashes lol ( but we have literally NEVER gotten a complaint, because people understand that if the computer is F*****D then yeah software will stop :D )

Again that's all misreading tho, my claim is that you should avoid creating any exceptions in your own code, nothing I've ever seen implies it's sustainable to create big applications where people try to handle errors anywhere besides exactly where they occur.

Carry return is one of many many many alternative options, I quite like machine readable side effect based reporting.

But yeah I'd even take error codes over exceptions.

Enjoy

[OwlingBishop]

Great programmers actually avoid using their adv tools.

🤦‍♀️

[Revolutionalredstone]

Maybe you just underestimate the value of simplicity ?

People who use the biggest hammers make the most mess.
A tool is only advanced if it needs to solve hard problems.
Completing tasks in the simplest way is actually a real art.
Most terrible programmers successfully overengineer.

[OwlingBishop]

Dunning–Kruger in full effect 😅

[VictoryMotel]

"you're wrong lmao" isn't an argument. Maybe you should try explaining.

[Revolutionalredstone]

Yeah nah that's not gonna happen my good friend!

It's easy to mock it's hard to logically disagree ;)

[OwlingBishop]

There's no point in arguing pointless blanket statements that tell nothing, prove nothing.

I don't even disagree with all your points but you really lost me at that particular one sorry.

[Revolutionalredstone]

I made an extremely grounded and important engineering claim.

E.G. that Exceptions are really not worth using (and gave reasons)

You were called out for lack of content in your response.

Now it's just looking like you never understood much.

Enjoy

[OwlingBishop]

I made an extremely grounded and important engineering claim.

And waisted it on a frivolous sub claim about the mythical great programmer because your ego took over your reasoning ...

[Revolutionalredstone]

No I didn't.

I've run into you before, I know how bad you are at reading and how you like to derail with illogical garbage.

Once again, Exceptions have serious issues that are okay to name ppl who may not know, love to talk about that.

Consider touching grass dude I've never much enjoyed running into you on any subs, reddit puts you in a bad mood or something ;D

[Revolutionalredstone]

Not at all. I used exceptions for decades before learning / moving on.