allow users to trap errors from runAsync

[bugzpodder]

Currently errors are trapped by try/catch statement in runAsync, eg:

   runAsync: async (interpreter, code, ...args) => {
        try {
            return await interpreter.doString(clean(code), ...args);
        }
        catch (error) {
            io.get(interpreter).stderr(error);
        }
    },

As a polyscript user I would like to have more granular control on the error being returned from runAsync.

The reason is that there are multiple scripts running on the page outputting to different parts of the page and I need to know which script caused the error and what the error is. Using io seems too restrictive and I want to be able to handle the error more freely.

[WebReflection]

As a polyscript user I would like to have more granular control on the error being returned from runAsync.

that's what the io field in define is for, you can fine-tune anything you like, like we will do in PyScript soon.

Please see the documentation around io field when defining custom types ... you can postMessage the error instead, if that's what you are after, or do anything you like, really ... the stderr utility is there exactly to address this use case.

Anything in particular you belive is not working after defining that io.stderr yourself?

[bugzpodder]

Yes. If I have two blocks of code I have no idea which one triggered io.stderr.
Generally the expectation in js land is if a function is async, it might throw an error and I can catch it. This is not the case here.

this is for main thread so I don't need to use postMessage

[WebReflection]

it was a PyScript requirement to be able to intercept errors and show these gracefully or in a custom way ... what you are asking is to re-throw the error as it is after invoking stderr which would result into duplicated errors shown in console if you don't define your own io field ... hence I am not sure what you are asking ... you can define your own stderr and throw errors out of the blue there instead of just logging, or posting these around ... right?

what is it that you are trying to achieve? What is "more granular control" if you can fully control what an error does already?

[WebReflection]

on a second though, maybe you want a return value that's not just undefined when an error occur? if that's the case, we could think about a solution to that ... but it might require a Symbol you should import and check against its reference to disambiguate with the rest of possible return values ... would that work?

import { ERROR } from 'polyscript';

// ...

const result = interpreter.runAsync(stuff);
if (result === ERROR) {
  // do your thing
}

[WebReflection]

P.S. if you throw in your custom io.stderr you would solve your issue ... but dare I say my latest suggestion might be desired for ourselves too ... please let me know if that would work for you too, thanks!

[bugzpodder]

ok thats an interesting proposition, throwing in io.sterrr. probably would work for my case..

[bugzpodder]

If I have two blocks of code I want the errors to be displayed next to each piece of code. Thats the use case i am trying to aim for.

[WebReflection]

If I have two blocks of code I want the errors to be displayed next to each piece of code. Thats the use case i am trying to aim for.

that's what we'll probably do with PyScript too so I think the current primitive should offer you all you need.

About throwing, and seeing all the details:

io: {stderr(error) {
  throw error;
}}

However, it's true you have no node reference there but that's inevitable because these functions work both on main and workers, where no reference exists ... maybe we can find a way to define the target ID and somehow pass it along while these callbacks are invoked, but I am not sure how that could ever look like.

Throwing will ensure your code stops whatever it's doing ... and in PyScript "classic" all errors are just shown piled, no reference to the script in the page running these ... the question though is: why do you use multiple scripts at all? each script bootstraps a runtime a part, if the env or the config is different, but you can always combine all of them into one script, which is ideal for both you and this project to handle.

[WebReflection]

but I am not sure how that could ever look like.

actually I do ... beforeRunAsync hook gives you a way to store anywhere the current element id, and you can use that info to reach the place where the error occurred ... as you use async results might vary because if you invoke 2 callbacks simultaneously, first come, first serve .... if you don't though, you're good.

[bugzpodder]

the question though is: why do you use multiple scripts at all? each script bootstraps a runtime a part, if the env or the config is different, but you can always combine all of them into one script, which is ideal for both you and this project to handle.

I have multiple charts (eg matplotlib) and each chart is a piece of python code. If something wrong with the code I would show an error in place of the chart. Combining them won't help because of variable conflation and error handling, and I don't want to do this extra work anyway.

[WebReflection]

but do you need those charts in main? they will block and if you try to parallelize these these would block way more ... if you use workers then you have display to show either results or error, if you don't you should resolve each chart one after the other so you won't have issues in there neither ... I think you are, however, mixing too much JS, main, and pyodide on main ... it can work, but your logic is screaming for issues to me, either out of blocked thread, or out of indirections to handle your use cases. I would instead use a worker, 1 to many targets, and store files as a config for the worker so you never block and each chart can be shown one after the other.

[WebReflection]

P.S. to explain where I come from, multiple PyScript "classic" on a page never really worked by design ... hence my questioning around why suddenly you want to do that ... is it really needed?

[bugzpodder]

Currently workers doesn't work in my app (due to the crossOriginIsolated headers being too strict, no SharedArrayBuffer access) so yes I am using main-thread and it works fine for me.

I could use display to show the results, but not all errors are in user land. For example there is a typo in the code and pyodide complains, or there are some OOM issues.

I've able to render 12 charts on the main thread no problem, with 100k points each. Not ideal but it works, and perf is not that bad.

Yes all chart code is resolved one after another.

[bugzpodder]

Here is a screenshot of what I am building. This is a fake screenshot from home page but the real product looks more or less similar, has polyscript/pyodide + webR support and it works reasonably well: