Workbench

Workbench copied to clipboard

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

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.

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.

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.

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

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

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

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

Yes that would be nice