> I don't know how Rust's RAII deals with exceptions thrown by lower level code.

Unwinding across an FFI boundary is considered undefined behavior.

https://doc.rust-lang.org/reference/behavior-considered-unde... last bullet point.

That's exactly what I wanted to know. Thanks!

Full D is compatible with foreign exceptions and unwinding. I'll see about making D as Better C also compatible, but I suppose Rust's precedent makes it acceptable to not handle it.

No problem!

This isn't my super strong area of expertise, but don't you have to specify how the unwinding works? I believe this is part of the reason why Rust punted; you'd have to specify exactly what kind is supported. (Rust uses libunwind for panics, incidentally.)

The how is handled by providing a language-specific "personality" function in the generated exception tables. The D runtime library has one for D. But with D as Better C, I'd have to find a way to make the C personality function work for D.

Ah right, makes sense. Thanks :)

If you mean lower level Rust code, there are no exceptions. Errors are just regular values encoded in the type system. If you're familiar with OCaml optionals and results, it's the same thing

There's a subtlety here: panics are exceptions, but they can be disabled without also disabling RAII.

How does it work if an exception gets thrown through a C stack frame that has outstanding resources (for instance, pointers that are freed later in the frame)? Are you referring to manual SJLJ?

In any case, it seems like C manual destruction has exactly the same problems as with RAII, because fundamentally the issue is passing exceptions through something that doesn't understand it, rather than with RAII.