Comment by quotemstr
4 hours ago
> That is the reason why mature error handling libraries hide the error behind a thin pointer, approached pioneered in Rust by failure and deployed across the ecosystem in anyhow. But this requires global allocator, which is also not entirely zero cost.
No, it doesn't require a global allocator. You make the thinly-pointed-to error object have a vtable and, in this vtable, you provide a "deallocate" or "drop" function. No need for a single global allocator.
> (this requires the errors to be register-sized).
Uh, what? No, you can make it a pointer, and honestly, in every real-world ABI, there are tons of callee-clobbered registers we COULD use for errors or other side information and just... don't.
Good upvote-worthy points, I'd just say that this is exactly the issue - eventually you end up with a Java++ implementation of exceptions.
As you say, the more limited implementation can be done more efficiently than the post post claims, but it has to be restricted and managed in a way that existing runtimes/compilers/languages haven't succeeded at so far... "just say no" earlier.