We could have something like an emitter function. This would probably still raise/throw under the hood, but it would allow for more control over errors.

The easiest thing we could do with the existing code would be to serialize the Z5, convert to string, and raise/throw:

# Python
def propagateError(Z5):
    raise Exception(json.dumps(serialize(Z5)))

# JS
async function propagateError( Z5 ) {
   throw new Error( JSON.stringify( await serialize( Z5 ) ) );
}

Then, when we catch the error (as we currently do), we can try parsing the error string to see if it's a Z5. We should also make some utility functions for Z5s, since it would be cumbersome right now.

~

The alternative would be to expose Z22 in user-space, i.e. make every function return a Z22, but I am loath to do that. I think it's a desirable trait to let people use the most comfortable coding paradigms in each native language; it is then our task to wrap those paradigms in clear and unsurprising ways.

In T305557#8260447, @cmassaro wrote:

We could have something like an emitter function. This would probably still raise/throw under the hood, but it would allow for more control over errors.

The easiest thing we could do with the existing code would be to serialize the Z5, convert to string, and raise/throw:

…

Then, when we catch the error (as we currently do), we can try parsing the error string to see if it's a Z5.

That could work reasonably well.

We should also make some utility functions for Z5s, since it would be cumbersome right now.

Yes. :-)

The alternative would be to expose Z22 in user-space, i.e. make every function return a Z22, but I am loath to do that. I think it's a desirable trait to let people use the most comfortable coding paradigms in each native language; it is then our task to wrap those paradigms in clear and unsurprising ways.

Yeah. The advantage of exposing the whole Z22 is that people could write arbitrary keys to it directly (rather than by calling Z820), but I agree.

The alternative would be to expose Z22 in user-space, i.e. make every function return a Z22, but I am loath to do that. I think it's a desirable trait to let people use the most comfortable coding paradigms in each native language; it is then our task to wrap those paradigms in clear and unsurprising ways.

Yeah. The advantage of exposing the whole Z22 is that people could write arbitrary keys to it directly (rather than by calling Z820), but I agree.

We have precedent for this. The serialization isomorphisms in Python at present are ...

so we can just make a custom ZError type to capture objects whose type is given by calling Z885. No need to call Z820.

Or rather, we'll just be duplicating Z820 in the executors, but ... whatever, it's not adding complexity, just wrapping some existing functionality more predictably.

Change 837192 had a related patch set uploaded (by Cory Massaro; author: Cory Massaro):

[mediawiki/services/function-evaluator@master] Add better support for errors in native code.

https://gerrit.wikimedia.org/r/837192

For whoever takes this over, there's a WIP patch here: https://gerrit.wikimedia.org/r/c/mediawiki/services/function-evaluator/+/837192

Change 837192 abandoned by Cory Massaro:

[mediawiki/services/function-evaluator@master] Add better support for errors in native code.

Reason:

This was a proof-of-concept; it's been referenced for posterity/whoever wants to take the bug over, but it need no longer darken the Your Turn door of two people in Gerrit

https://gerrit.wikimedia.org/r/837192