[KerrAvon]

For one thing, they’re expensive and viral. “Zero overhead” implementations don’t take into account the need for unwind tables. For every function/method that might be thrown across. They’re disabled in a lot of production environments for this reason.

[neonz80]

There was an interesting talk about C++ exceptions in smaller firmware at CppCon last year: https://youtu.be/bY2FlayomlE

Basically, the overhead of exceptions is probably less than handling the same errors manually in any non-trivial program.

Also, it's not like these table doesn't exist in other languages. Both Rust and Go have to unwind.

[amelius]

But if you explicitly handle exceptions using IF statements then that's overhead too, right?

[arbitrandomuser]

yes but i think branch prediction essentialy makes them zero overhead

[neonz80]

That's a different type of overhead than having unwind tables. With exceptions you wouldn't need a branch after each function call at all.

[amelius]

But a branch that is (almost) never taken has an overhead close to the overhead of a NOP instruction, which may be negligible on modern architectures.

[neonz80]

The CPU can not remember an infinite number of branches. Also, many branches will increase code size. With exceptions the unwind tables and unwind code can be placed elsewhere and not take up valuable L1 cache.

[amelius]

> The CPU can not remember an infinite number of branches.

I suspect a modern CPU has a branch instruction saying "This branch will never be taken except in exceptions, so assume this branch is not taken". But I must admit I haven't seriously looked at assembly language for some time.

(EDIT: yes, modern CPUs including x86 and ARM allow the programmer/compiler to hint if a branch is expected to be taken).

> Also, many branches will increase code size.

I'd like to see some data on that. Of course branches take code size, but how much is that percentage-wise? I suspect not much.