<p>I'm looking for a guide for implementing exceptions in a language with explicit memory management like C++. However, the language's type system and exception handling semantics are incompatible with C++. Is there some guide on how to do this?
I already found the <a href="https://llvm.org/docs/ExceptionHandling.html" rel="nofollow noreferrer">llvm docs</a> and some <a href="https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html" rel="nofollow noreferrer">Itanium ABI docs</a>.
However, the former is incomplete and the latter seems not to reflect what is currently implemented in the sense that the actual implementation is slightly less.
Also, the LLVM part seems to assume that it is fine to use __gxx_personality_v0 which likely isn't the case for me.</p>

<implementation><standard-library><c++><llvm><exceptions>
Is there a guide for implementing exceptions in languages with explicit memory management?
CC BY-SA 4.0
2024-07-10T02:09:39.487Z
Do you need an explanation for how to free manually-managed resources when unwinding the stack? C++ does this with RAII; if an exception goes through a frame with any heap-allocated pointers or other data that doesn't destruct at the end of the scope, that data will leak.
tarzh
CC BY-SA 4.0
2024-07-10T02:11:09.097Z
Other languages, like [Zig](https://ziglang.org/documentation/master/#Errors) and Jai, don't have exceptions in the traditional sense, but "errors" that must be manually handled like [Rust's`Result` type](https://doc.rust-lang.org/std/result/enum.Result.html). Personally I'd recommend following Rust here, because then all you need for "exceptions" are built-in support for tagged unions and syntax sugar (or also follow [Go](https://gobyexample.com/errors) and don't even have those).
tarzh
CC BY-SA 4.0
2024-07-10T15:03:22.830Z
Explicit memory management is a red herring here, what you are looking for is deterministic destruction (via destructors) on unwinding. This is used to implement memory handling, so the overlap is strong, but there may be languages with deterministic destructor calls that do not feature explicit memory management.
Matthieu M.
CC BY-SA 4.0
2024-07-10T15:04:29.413Z
You could try looking at the source of the Rust compiler. It uses both LLVM and the cranelift backend (experimental) so this would show you how "landing pads" are generated, and how to use LLVM for this in general. No idea how approachable that is, though...
Matthieu M.
CC BY-SA 4.0
2024-07-10T19:12:57.290Z
@MatthieuM. Before starting the implementation of Tyr exceptions I would likely have agreed, but now I thinkt that most newer languages avoid exceptions because implementing them correctly is really hard. The llvm docs sufficiently explain generation of landingpads already. But they do it implicitly and likely unknowningly assuming that the language is somewhat similar to C++. Its more on a level should I start implementing my own personality and everything around it or should I make it closer to C++ wrt. CFG layout.
feldentm
CC BY-SA 4.0
2024-07-10T19:14:16.757Z
@tarzh I appreciate your comment, but I'm looking for something one or two layers below your level of abstraction I guess. Also, I would like to not break the C++ infrastructure.
feldentm
# Is there a guide for implementing exceptions in languages with explicit memory management?
Posted by: username_0 on 2024-07-09
I'm looking for a guide for implementing exceptions in a language with explicit memory management like C++. However, the language's type system and exception handling semantics are incompatible with C++. Is there some guide on how to do this?
I already found the [llvm docs](https://llvm.org/docs/ExceptionHandling.html) and some [Itanium ABI docs](https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html).
However, the former is incomplete and the latter seems not to reflect what is currently implemented in the sense that the actual implementation is slightly less.
Also, the LLVM part seems to assume that it is fine to use \_\_gxx\_personality\_v0 which likely isn't the case for me.
**Tags:** implementation standard-library c++ llvm exceptions
> **Comments:**
> **username_1**: Do you need an explanation for how to free manually-managed resources when unwinding the stack? C++ does this with RAII; if an exception goes through a frame with any heap-allocated pointers or other data that doesn't destruct at the end of the scope, that data will leak.  
> **username_1**: Other languages, like [Zig](https://ziglang.org/documentation/master/#Errors) and Jai, don't have exceptions in the traditional sense, but "errors" that must be manually handled like [Rust's`Result` type](https://doc.rust-lang.org/std/result/enum.Result.html). Personally I'd recommend following Rust here, because then all you need for "exceptions" are built-in support for tagged unions and syntax sugar (or also follow [Go](https://gobyexample.com/errors) and don't even have those).  
> **username_2**: Explicit memory management is a red herring here, what you are looking for is deterministic destruction (via destructors) on unwinding. This is used to implement memory handling, so the overlap is strong, but there may be languages with deterministic destructor calls that do not feature explicit memory management.  
> **username_2**: You could try looking at the source of the Rust compiler. It uses both LLVM and the cranelift backend (experimental) so this would show you how "landing pads" are generated, and how to use LLVM for this in general. No idea how approachable that is, though...  
> **username_0**: @MatthieuM. Before starting the implementation of Tyr exceptions I would likely have agreed, but now I thinkt that most newer languages avoid exceptions because implementing them correctly is really hard. The llvm docs sufficiently explain generation of landingpads already. But they do it implicitly and likely unknowningly assuming that the language is somewhat similar to C++. Its more on a level should I start implementing my own personality and everything around it or should I make it closer to C++ wrt. CFG layout.  
> **username_0**: @tarzh I appreciate your comment, but I'm looking for something one or two layers below your level of abstraction I guess. Also, I would like to not break the C++ infrastructure.  
---
## 0 answers
