Isn't it generally undefined behaviour to have exceptions pass through code that isn't compiled with support for them? I.e. not running some destructors is the least of your worries if an exception hits C/-fno-exceptions/-betterC code.

Undefined behavior or not, implementations of languages in gcc and Windows tend to support it, even if the language itself does not. I consider it my job to make this work if at all practical, because users do not like ugly surprises.

I don't know how Rust's RAII deals with exceptions thrown by lower level code. If someone better acquainted with Rust could chime in here, it would be interesting.

> 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.

Gotcha. C++ has the same problem when its exceptions are thrown through C or -fno-exceptions C++ frames.

If that's the only hold-up, IMO the way to go is to abort at the boundary, when an exception would propagate into frames without unwind tables. RAII is too valuable to do without!