Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use value-based exception handling #99

Open
jeaye opened this issue Oct 6, 2024 · 2 comments
Open

Use value-based exception handling #99

jeaye opened this issue Oct 6, 2024 · 2 comments

Comments

@jeaye
Copy link
Member

jeaye commented Oct 6, 2024

jank already uses value-based errors for internal systems, such as the lexer and parser, but Clojure-looking systems use exceptions. On top of that, Clojure itself demands support for throw and try. In those areas, we're using exceptions. This limits the portability of jank, though, and it comes at a cost in binary size as well as performance in those exceptional scenarios.

Chris Lattner explains here how Mojo is replicating exception semantics using value-based errors. This enables much more portability, such as running on both embedded systems and also GPUs, where exceptions may not be usable.

In short, he described it this way: If every function returns a result<T, E>, we can replicate exception semantics like so.

  1. throw just becomes an early return with an error value
  2. Every function call gets its result checked and, if it's an error, the function early-returns the error (which then gets returned upward)
  3. try becomes an extra bit of logic that, rather than early returning on an error, jumps to the catch block (and, if needed, the finally afterward)

So this will require some codegen work. It will also require removing all exception throwing/catching from jank's code, in favor of result usage. This is the direction I've been pushing jank and Chris' confirmation here only helps with that momentum.

NOTE: If we want to compile with -fno-exceptions, we'll also need to remove any dependencies (including the C++ stdlib) which are using exceptions. This may be a huge undertaking.

@crmsnbleyd
Copy link

Is this now just a "simple" task of implementation or is there more design left to be done?

@jeaye
Copy link
Member Author

jeaye commented Dec 21, 2024

Is this now just a "simple" task of implementation or is there more design left to be done?

I think that it's mainly down to tackling the huge implementation at this point. We'd need to remove exceptions from everywhere in jank and replace them with result<T, E>. From there, we can change function codegen to always return a result type, too. Overall, it's likely a couple months worth of work, which is why I can't prioritize it until after jank is released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants