Great paper. but i think several important things are missing.

[trcrsired]

1. it is very hard or impossible to implement exceptions on many platforms. Half of my cross toolchains simply do not have working implementations due to implementation difficulties.
   web assembly. operating system kernel.
   I recently dealt with wasm2lua, it would compile C++ code to Lua. There is no way to implement exception handling in lua.

https://youtu.be/_1Dob0kb8pw

2. Runtime bloat. The EH runtime would bloat at least 50kb with libgcc_eh + 100kb if you use things like std::string (since they throw std::logic_error). It is very a large runtime that is not worth it at all.

3. Every function could throw if it is not marked as noexcept, particular C functions.

4. Still a lot of implementations are using setjmp longjmp, including 32 bit windows and emscripten (well the exceptions in emscripten is using js exceptions to emulate setjmp/longjmp)

5. Talking about the performance of "happy path" is totally nonsense because a lot of so-called "bad-path" could simply be dealt with a std::abort to crash the program, instead of throwing exceptions and that provides much better performance than EH.

I do not think even breaking abi would solve the fundamental issue being C++ EH is terribly designed in the first place. The implementation difficulty of C++ EH is not going to be solved by breaking ABIs. Bjarne is wrong at this.
https://www.youtube.com/watch?v=I_ffAFzi-7M

P0709 is the only solution EXCEPT I hope std::error is not going to screw up due to heap allocation with stringref thing.

Same with iostream. Things like std::format are actually making things much worse instead of better.

In general, WG21 has a very bad priority and a lot of incompetent committee members. C++ freestanding does not even provide std::addressof, std::move, std::forward (no std::array of course), even std::addressof relies on compiler magic. Also, LLVM libc++ refuses to provide the freestanding implementation. Despite Bjarne and other standard C++ people believing C++ is very good at writing operating system, they are totally wrong about this. C++ is terrible for kernel development.

https://www.youtube.com/watch?v=DorYSHu4Sjk
https://www.youtube.com/watch?v=B1KB1U3HPKo

[neumannt]

I never did any any embedded development, but I do not get why you cannot implement traditional C++ exceptions in lua. After all, you do not have to use unwinding tables, you can just as well return an exception flag as return value if you control the ABI (which you clearly do when you produce lua code) and pass the exception itself in a thread local side channel. The difference between Herbceptions and traditional exceptions is not that large in that respect, it is just the typical implementations that differ. In fact I would guess that you could even implement traditional exceptions reasonably well on an embedded platform if you accepted some moderate restrictions, like a maximum exception size and a maximum number of exceptions that can be in flight, which would allow you to pre-allocate memory for potential exceptions. You could forget the unwinder and simply check an exception flag after every non-noexcept call, just like Herbceptions.

The only problem is compatibility with existing binaries in other languages, because these would obviously not propagate the exception information. When translating your binary to lua that should not be a problem, though, it simply costs you an if after every non-noexcept call?

[trcrsired]

I never did any any embedded development, but I do not get why you cannot implement traditional C++ exceptions in lua. After all, you do not have to use unwinding tables, you can just as well return an exception flag as return value if you control the ABI (which you clearly do when you produce lua code) and pass the exception itself in a thread local side channel.

There is no thread local side channel in the lua I am working with. It is impossible to implement due to lack of unwind mechanism.

Plus you have to first translate C++ to wasm and then translate wasm to lua, most information is lost.

Huge runtime bloat is another issue.

LLVM simply does not support wasm EH.

Also, i do kernel development, none of them supports EH. Heap allocation is an even larger issue due to not being interrupt safe. C++ EH basically requires a POSIX compliant system which is not possible to use in kernel.

Implementing EH is super costly and does not worth the cost at all. It basically requires every platform to implement a new unwinding mechanism. The cost of implementing EH is way beyond to just replace the device with a more powerful machine (not acceptable either)

[trcrsired]

https://bitbucket.org/ejsvifq_mabmip/x86_64-elf-baremetal-toolchain

Here is a freestanding C++ toolchain. No std::array, no std::move, no std::addressof. No EH runtime of course. You just simply does not have EH and not even things like std::addressof ( based on ISO C++ standard std::addressof and std::move are not freestanding)
You are not allowed to get the address of an object.

Linus torvalds was totally right at this issue. C++ EH is completely broken and even more broken in kernel.

[trcrsired]

https://youtu.be/BMAy6SXtcfk
https://youtu.be/4I7XZiS0ru4

[neumannt]

Linus torvalds was totally right at this issue. C++ EH is completely broken and even more broken in kernel.

don't get my wrong, I agree that the current exception design is highly suboptimal, and I would rather prefer something like Herbceptions (except for the source code compatibility issues the current proposal has).

But I think you have to distinguish between existing implementations and what could be implemented given the language specification. Even traditional exceptions could be implemented reasonably well, definitively much better than what we currently have, and potentially even suitable for a kernel, if you forbid 1) "throws;" outside of catch blocks, and 2) current_exception, ideally everywhere, definitively outside catch blocks. The language does not force you to use unwinding tables and this complicated dance with exception allocations, at least not if you accept the two restrictions mentioned above. It is just current implementations that do that.

[trcrsired]

But I think you have to distinguish between existing implementations and what could be implemented given the language specification. Even traditional exceptions could be implemented reasonably well, definitively much better than what we currently have, and potentially even suitable for a kernel, if you forbid 1) "throws;" outside of catch blocks, and 2) current_exception, ideally everywhere, definitively outside catch blocks. The language does not force you to use unwinding tables and this complicated dance with exception allocations, at least not if you accept the two restrictions mentioned above. It is just current implementations that do that.

I do not think so. The traditional exception is designed very wrong in the first place because it is to terminate the program, not to handle errors. HP designed this with a totally wrong philosophy since these companies do not want their program to crash EVEN program is bugged.

The design is wrong, just like iostream. They are not implementation issues. Implementation issues only happen when you wrongly design the things in the first place.

https://youtu.be/cbUTAoHy6Ls?t=1525

[FrankHB]

Runtime bloat. The EH runtime would bloat at least 50kb with libgcc_eh + 100kb if you use things like std::string (since they throw std::logic_error). It is very a large runtime that is not worth it at all.

That's mostly nonsense. It should at least hurt almost nothing in the host implementation which deploys the runtime in some shared library, and there should only be one copy. (It's certainly your business if you want to link it statically in every userland apps.)

The cost of such "runtime" is just like the hardware implementation, which is dedicating and not expected to be "zero-overhead". It is always there, unconditionally. Blaming that "bloat" is like blaming the customer too poor to have sufficient RAM in the machine. (Not like the cache, because this should disturb nothing else besides the "bloat".)

And if it has been implemented in the microarchitecture registers or μROM in the CPU, will you try to uninstall it? Actually there are already many similar instances you won't use forever...

Blame system vendors if you merely don't want to see it implemented in software.

[trcrsired]

Runtime bloat. The EH runtime would bloat at least 50kb with libgcc_eh + 100kb if you use things like std::string (since they throw std::logic_error). It is very a large runtime that is not worth it at all.

That's mostly nonsense. It should at least hurt almost nothing in the host implementation which deploys the runtime in some shared library, and there should only be one copy. (It's certainly your business if you want to link it statically in every userland apps.)

The cost of such "runtime" is just like the hardware implementation, which is dedicating and not expected to be "zero-overhead". It is always there, unconditionally. Blaming that "bloat" is like blaming the customer too poor to have sufficient RAM in the machine. (Not like the cache, because this should disturb nothing else besides the "bloat".)

And if it has been implemented in the microarchitecture registers or μROM in the CPU, will you try to uninstall it? Actually there are already many similar instances you won't use forever...

Blame system vendors if you merely don't want to see it implemented in software.

except android does not even ship libunwind and the modern walled garden app sandboxing is in general very hostile to adding custom shared libraries

[trcrsired]

Android is taking over the world and it has no EH support