Error handling #5

New issue

Open

opened 2025-05-09 00:41:08 +02:00 by lucas · 1 comment

lucas commented

2025-05-09 00:41:08 +02:00

Owner

Figure out a strategy for error handling.

The simple approach would be to only stick to what Lua can do, i.e. calling lib_argerror or lib_error right where the error happens. But that also removes all the nice stuff that error handling in Rust is capable of.

because it's a longjump, functions just suddenly stop where it happens, which is hard to model in Rust's type system and might not properly drop values
if/when I do have proper Results to work with (from libraries, or in my own functions), it becomes a weird mix
the recovery mechanism is tedious, since even the best option (lua_cpcall) still wants a lua_CFunction, not a Rust function

So I think the better approach will be to build a wrapper function and a thiserror enum that allow me to do the normal Results everywhere, which are then translated right at the boundary.
That wrapper could also catch panic!()s (maybe limited to debug mode).

And I think I will only need two implementations of that wrapper. One for the functions that get called by the engine (e.g. setup_game) and one for the ones called by Lua. Those should be the only two signatures that need to be covered.

Figure out a strategy for error handling. The simple approach would be to only stick to what Lua can do, i.e. calling `lib_argerror` or `lib_error` right where the error happens. But that also removes all the nice stuff that error handling in Rust is capable of. - because it's a longjump, functions just suddenly stop where it happens, which is hard to model in Rust's type system and might not properly `drop` values - if/when I do have proper `Result`s to work with (from libraries, or in my own functions), it becomes a weird mix - the recovery mechanism is tedious, since even the best option (`lua_cpcall`) still wants a `lua_CFunction`, not a Rust function So I think the better approach will be to build a wrapper function and a `thiserror` enum that allow me to do the normal `Result`s everywhere, which are then translated right at the boundary. That wrapper could also catch `panic!()`s (maybe limited to debug mode). And I think I will only need two implementations of that wrapper. One for the functions that get called by the engine (e.g. `setup_game`) and one for the ones called by Lua. Those should be the only two signatures that need to be covered.

lucas added the

labels 2025-05-09 00:41:08 +02:00

lucas added this to the v0.1 milestone 2025-05-09 00:42:56 +02:00

lucas commented

2025-05-11 12:38:52 +02:00

Author

Owner

There may also be errors that aren't directly related to a Lua function call, and we can't just call lua.lib_error.

For those, it might be necessary to store a list of errors that occurred, maybe with an extra is_fatal flag, and then expose a module function where the Lua-side can occasionally fetch them, and display them.

That would also allow to show errors in the usual UI popup. In the log, they are useful for debugging, but a display in the UI is certainly better to make the user aware.

There may also be errors that aren't directly related to a Lua function call, and we can't just call `lua.lib_error`. For those, it might be necessary to store a list of errors that occurred, maybe with an extra `is_fatal` flag, and then expose a module function where the Lua-side can occasionally fetch them, and display them. That would also allow to show errors in the usual UI popup. In the log, they are useful for debugging, but a display in the UI is certainly better to make the user aware.