Cannot inspect Rust panics

[Hofer-Julian]

If Rust fails to compile, the error message is nicely visible in the console.
However, if Rust panics at runtime, all you get is:

(re.sonny.Workbench.Devel:4): Gjs-WARNING **: 20:30:17.056: Unhandled promise rejection. To suppress this warning, add an error handler to your promise chain with .catch() or a try-catch block around your await expression. Stack trace of the failed promise:
  save@resource:///re/sonny/Workbench/Document.js:18:8
  Document/start/handler_id<@resource:///re/sonny/Workbench/Document.js:27:7
  _init/GLib.MainLoop.prototype.runAsync/</<@resource:///org/gnome/gjs/modules/core/overrides/GLib.js:266:34

[sonnyp]

that error is solved but now we get

thread '<unnamed>' panicked at 'fpp', code.rs:15:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

(re.sonny.Workbench.Devel:4): Gjs-WARNING **: 01:38:11.242: JS ERROR: Gio.IOErrorEnum: Underlying GIOStream returned 0 bytes on an async read

(re.sonny.Workbench.Devel:4): Gjs-WARNING **: 01:38:11.242: JS ERROR: Gio.IOErrorEnum: The connection is closed
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:114:23
_init/GLib.MainLoop.prototype.runAsync/</<@resource:///org/gnome/gjs/modules/core/overrides/GLib.js:266:34

and the console clears after "fatal runtime error: failed to initiate panic, error 5"

Should we run Rust with `RUST_BACKTRACE=1 ?

Not sure what we can do about the Gjs WARNING, looks like DBus related but we could at least prevent the console from clearing.

[Hofer-Julian]

and the console clears after "fatal runtime error: failed to initiate panic, error 5"

I guess we should catch the panics at the API level, return exit code 1 and then handle that on the previewer side.

Should we run Rust with `RUST_BACKTRACE=1 ?

I don't think that's necessary. This is mostly useful to debug panics deep in your stack trace.

[Hofer-Julian]

While handling errors properly would be nice, for now it would already be good if the console wouldn't clear the screen when the previewer crashes.

[sonnyp]

I can do that. Do you have a reproducer for crashing the previewer?

[Hofer-Julian]

I can do that. Do you have a reproducer for crashing the previewer?

That would be great. You can reproduce e.g. by trying to access a builder object that doesn't exist.

Or just call panic! directly

[sonnyp]

Tricky. The console only clears after compiling is successful, but there is some kind of race condition and the first lines in VTE get eaten too.

Compiling demo v1.0.0 (/home/sonny/.var/app/re.sonny.Workbench.Devel/data/re.sonny.Workbench.Devel/sessions/2023-09-24 23-21-09)
Finished dev [unoptimized + debuginfo] target(s) in 0.40s
re.sonny.Workbench.Devel-Message: 23:27:00.087: clear <<<<<<<<<<<< everything after this should be visible
thread '' panicked at 'Subtitle box not found', code.rs:7:10

I'll dig further when I have a moment

[sonnyp]

thread '<unnamed>' panicked at code.rs:223:56:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

(re.sonny.Workbench:5): re.sonny.Workbench-CRITICAL **: 14:02:25.804: Gio.IOErrorEnum: Underlying GIOStream returned 0 bytes on an async readundefined

(re.sonny.Workbench:5): re.sonny.Workbench-CRITICAL **: 14:02:25.805: Gio.IOErrorEnum: The connection is closed
asyncCallback@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:114:23

Since the panic gives the line number it would be good to use that.

One way to solve this that I would like to do anyway is to stop redirecting subprocess stdout to Workbench's

[Hofer-Julian]

Yes that would be nice