`System.exit` makes GUI unable to initialize the project - don't exit the sandbox!

[radeusgd]

This is partially expected, but I'm wondering if we should explicitly disallow usage of System.exit inside of GUI.

Because it shuts down the process, it kills the Language Server before it gets a chance to initialize.

The biggest problem is - the user can insert the System.exit node into a workflow, but afterwards it becomes impossible to remove it. Because to remove it the Language Server needs to initialize, but it shuts down before it has the chance to do so - breaking such a workflow completely, until it is manually edited in an external editor.

[radeusgd]

We definitely do not want to allow System.exit from breaking the Language Server.

Perhaps it should Panic if ran in interactive mode instead?

[farmaazon]

Shouldn't System.exit exit the current execution instead of the entire process in this case?

I imagine GUI just receiving "Execution failed" message with "exited with code X" or something along.

[JaroslavTulach]

Truffle offers a sandboxed way of doing exit. Instead of calling System.exit directly one should throw an exception with exit status. The exception shall be caught by language server and exit status shall be reported to the GUI, but the JVM shall not exit itself. Or:

As of 22.0 Truffle has support for polyglot context hard explicit exit triggered by guest languages using TruffleContext.closeExited(Node,int). It provides a unified way for languages to trigger the exit of the underlying polyglot context.

More on Truffle exit.

[enso-bot[bot]]

Pavel Marek reports a new STANDUP for today (2024-07-15):

Progress: - Finished the PR for System.exit does not cause language server process termination

• QA for both cmdline and interactive execution.
• Support methods in type bodies inside the VSCode extension: https://github.com/enso-org/enso/pull/10560 It should be finished by 2024-07-15.