You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if model code panics, this crashes the whole app:
thread '<unnamed>' panicked at 'not yet implemented', models/test/src/lib.rs:7:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
not yet implemented
Aborted (core dumped)
This can be easily reproduced by adding a todo!()/panic!()/... to any model.
Panics can be a normal part of creating a model. They can happen accidentally, or even on purpose, when placing a todo!() somewhere. The app should handle that case well, and just show an error message under "Status".
fj-host, which is responsible for handling models, already expects that any interaction with a model can result in an error, and reports those errors to the GUI. I believe that no changes are required there. So we just need to make sure that whenever model code panics, this panic is converted into an error and returned to fj-host.
(It would be advantageous to instead catch panics on the host's side, to protect against malicious models. But I consider such protection a nice-to-have at this point, and out of scope of this issue. In addition, we need to catch those panics on the model side, as panics over an FFI boundary are undefined behavior, as far as I know. Maybe we can do better once we switch to WebAssembly.)
It looks like panics in the model are already handled, so all we need to do is check where that handler function is called, determine if it's practical to return an error there instead, and adapt the code to do so.
Currently, if model code panics, this crashes the whole app:
This can be easily reproduced by adding a
todo!()
/panic!()
/... to any model.Panics can be a normal part of creating a model. They can happen accidentally, or even on purpose, when placing a
todo!()
somewhere. The app should handle that case well, and just show an error message under "Status".fj-host
, which is responsible for handling models, already expects that any interaction with a model can result in an error, and reports those errors to the GUI. I believe that no changes are required there. So we just need to make sure that whenever model code panics, this panic is converted into an error and returned tofj-host
.(It would be advantageous to instead catch panics on the host's side, to protect against malicious models. But I consider such protection a nice-to-have at this point, and out of scope of this issue. In addition, we need to catch those panics on the model side, as panics over an FFI boundary are undefined behavior, as far as I know. Maybe we can do better once we switch to WebAssembly.)
It looks like panics in the model are already handled, so all we need to do is check where that handler function is called, determine if it's practical to return an error there instead, and adapt the code to do so.
Labeling https://github.com/hannobraun/Fornjot/labels/good%20first%20issue, as the scope of this problem is limited to a specific part of Fornjot, and knowledge about the rest of the system shouldn't be required to address this.
The text was updated successfully, but these errors were encountered: