Agoric SES, 23 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SES Meeting: Throwing through ShadowRealm and CallableBoundary

Description

Wherein Caridy leads a conversation about what to do about error and rejection events.

A

All right welcome to the assess meeting today is march 23. We have two topics today uh which both pertain to what happens when errors are well when anything is thrown out of either a shadow realm or a callable boundary charity.

B

Okay, so the first one.

C

B

Whether or not the um even.

C

Though get target custom event.

B

C

B

And so on should be global volumes that are provided by the host when a shadow realm is created and issue number 7591, um it seems that.

A

Yeah, could you give us more background about what those things are? I've uh haven't paid attention to the browser side of things in a long time.

B

Okay, so this one is specifically, I think they, the the simple case, is event target, whether or not event target should be a global value on a shuttle run if a.

A

Target is using.

B

Node and browsers to implement the regular eventing mechanism that you could use to listen and dispatch. Events on certain objects in the browser. The window is an event argument in shadow realm. The the global object is a ordinary object, so it's not an even target. Therefore, you cannot listen for events there. You cannot dispatch events there um and it seems that we are all in agreement that that should be the behavior. um So it's not a special in any case in in node. I believe it's the same thing.

B

The the question is whether or not we should even provide even target as a global value that people can use to create sub classes or create instances of it and so on, and- and it seems that uh consider that it is in node and in browsers it makes sense to have event target.

A

It's not in javascript.

B

It's not in javascript. Yes, these are the things that the host will be able to add to the global object.

A

So what is the current? So um so what else uh in the shot? According to the shadow realm spec, might the host add to the global object.

B

Can you repeat that question.

A

The what, according to the shadow, realms back what freedoms does the host have can.

C

A

C

Sorry anything as long as it's uh configurable.

A

So so then, this would already be allowed by the shadow realm spec.

B

A

So I don't understand what the issue is so.

B

The then the the secondary question of that or this I think the intel aspect of it is uh whether or not we want to expose promise, reject reduction event.

C

So is so you wouldn't go to the.

C

Let me try to see if I understand in um in in the ecmass page, there is hooks so that the host can report rejected promises and the global error handler is also a host integration.

C

um What the html integration does is take uh unhandled errors or unhandled promise, rejections uh and dispatch an event on the global, because the global in html is a an event uh target, so it can dispatch evidence. Did I summarize that right, I think so.

B

A

Okay, I think I think I just realized what I'm confused about. Let me, let me uh clear, um confirm uh we're not none of this would affect the shadow realm spec we're not talking about what should or should not be in the shadow realm spec we're talking about what should be in the html integration. Is that correct.

B

I I believe so so it's not really about the spec. It's about add to the other spec that defines what goes into shadow rom entrances global objects.

C

Right so currently, the existing promise rejection mechanism, the hooks that exist in the ecmaspec and obviously the global error handlers all those.

C

It doesn't matter which realm that happens in uh those hooks would keep from working, and the host would already be able to identify which realm uh that occurred in right.

C

Actually, I'm a little bit unclear on how the promise rejection uh hooks work uh and how that interacts with the realms.

B

Yeah, so let me, let's maybe maybe reshape the conversation, so the issue is really about the behavior of the global object uh or driven by the behavior of the global object, because in the shadow realm the global object is a um it's not a special. In any case, it's just a ordinary object is not an even target. Therefore, we cannot have a mechanism implemented in the host that will dispatch certain events into that global object.

B

Let's say that there is an error and one of the promises or some sort of error there, that surface as a global object in a regular web application.

B

So you can listen for those errors at the window level in a shadow realm they they will not work, because the global is not an event target and doesn't dispatch any of these units.

B

But the question is really about. If that, since that's the case, I plan to change that. That's the case. It is a ordinary object. Then what is the point of exposing a bunch of these globals into the shadow realm when you will not be able to use them directly with the global object that they shot around to create? But.

C

So the html spec could create an entry on the global. That's called like error handler or something like that. That is an event target that is installed in uh on the shadow realm uh global and which is the target used uh as uh to dispatch those events. Instead of being the global object directly, nothing prevents html from changing and doing that. So.

B

I think that's that's dominic's position, dominic is saying well, yes, the global object is not an event target. It doesn't dispatch this event. It doesn't do any of that, but still user lan code might create these structures, and even the host might create different objects that behave that way. So um it's just a a discussion of whether or not it makes sense to expose these global values into the shadow rom.

B

Even though the shadow round global object will not use it or the shadow realm itself will not use it in any ways, just giving them this these artifacts to developers, so they can use the same mechanics that they use in different environments.

C

I mean is: is that the case that uh the shadow realms wouldn't use it if, if html created a secondary object that can be used to register those heaven hunters in the context of a shadow realm?

C

Would errors unend all the errors and another uh rejections that happen in execution inside that uh shadow realm? Should they trigger that evidence, and I I think it's.

B

Awesome, that's the host! That's not that's not doing any of that yeah. So so.

B

First of all, this is the first time that I that I, that I hear about that particular proposal, and it does make sense to me and it's probably something that we can explore and then even bring it to the web, like the object that you can also use on the web in the same fashion, to do the same things, because the global one itself is confusing for some people, but um but that doesn't change the fact that we don't need to do anything on the on the shadow run spec to introduce this new global value in this in the 262 spec.

B

So I think that that might be host specific uh behavior.

C

Yeah, I I think the main thing that's important is that a uh an error uh handler on the I don't know how you want to call it incubator realm uh is not able to get error objects from inside shadow realms because that would break the boundary um so that that's one of those cases where the host integration needs to make sure it respects uh the shadow realm boundary, um and- and that's why I was trying to get at the next step- is that if you can't get unhandled rejections and unhandled errors that happen inside the shadow realm developers will expect to get that information somewhere else and somewhere else.

C

It would make sense for that to happen inside the shadow round itself.

B

Yeah, I think that reason is well for me as well. So again, the primary question is whether or not we have any objections to wholes adding those global values into um english from global object, uh even though the global object itself will not will never use.

A

Okay and and just to make sure I understood matthew's point just now: none of this implies any breaching of the shadow round boundary.

C

No, that's exactly why I want to make sure we don't breach it uh and that hosts are not allowed to. But since I have a feeling, they're gonna get the feature request to get error. Informations like that they're going to need to figure out where to expose this uh that doesn't violate the the callable binary.

A

Okay, so from the point of view of the tc39 shadow realm spec, um this is all completely neutral, correct. All right. Yes, okay,.

C

Yeah, I think I'm fine with the host at uh keeping evan targets making uh machinery inside shadow realms, and I think they will need it uh ultimately uh to expose unhandled errors and rejections uh inside shadow realms.

B

Okay, good good, so the second one uh issue number.

B

Three: five: three now.

C

Yeah, um so I guess that issue is what happens when code executing inside the shadow realm.

C

um Well, if you get a wrapped function and the uh inside function that it's wrapping, when you call it throws, um what should the error shape be um so you're gonna get a thrown uh something back through the callable binary, like the the rapper is going to rethrow something. The question question is: what is that rethrone thing should be.

A

Like to ask some clarifying questions.

C

A

uh So if you pass, let's say a number through the callable boundary, a number being, a primitive value goes through the callable boundary. uh If you return a number through the call of the boundary again, it just goes through the call, the boundary. uh If you throw a number through the call of a boundary.

A

uh What currently happens.

C

I think currently as specified it just throws a new tiger uh created in the color realm. I correct me if I'm on karate right, I.

B

Think it does a twist string on that one and then creates a type, a error on on the boundary yeah.

A

Okay, um so, okay, so good, so I understand that that answer I'll come back to it.

A

Now, um if you pat, if you make a call through the call boundary, passing an error as an argument, then that's just that that's just causes an error and the error that it causes is not has no information about the error that was rejected. The error that's rejected is simply rejected, because it's not an object that can go through the call boundary. It's not different than any other object.

C

It's basically a type or invalid argument, type of kind of error that doesn't even get into the the target. Well,.

A

Right and and uh and then and then, if you return an error, object through the call boundary, then the caller gets a a type error. That's unrelated to the error, and that's as it should be, because throwing the error and returning the error is not different than returning an object.

A

So I think that throwing an error should also not I mean, throwing an error and throwing an object if you're throwing an object. The error that you get would not be informative with regard to the object that was thrown. So if you throw an error, the error that you get should not be informative. With regard to the error that was thrown because otherwise you're privileging errors compared to objects.

A

Now the the with regard to developer experience. The point I want to make is that the only decent developer experience any developers any ever going to experience is when the carbon boundary is in turn, surrounded by membrane by you know, by the half membrane, on both sides to build a membrane and the membrane will never throw across the column boundary, because the membrane mechanism doing a an invocation will protect the unification with the try catch communicate through the call of boundary information about the the catch to be reproduced as a throw on the other side.

A

So you know the um so membranes already have to catch encode and rethrow errors, as well as to translate the throne value um just like it would, for you know or returned a return value or or a thrown object. So um I think trying to rescue the developer. Experience for people, programming below the the membrane level is just kind of hopeless, and if we keep trying to incrementally address it, we're just going to make a mess.

B

Yeah to add one more thing to the picture, which is what we discussed last week, I believe, is uh the um with respect to proxies and revoke proxy. Specifically, when you pass a revoked proxy, you return a revoked proxy. You also have the same the same type of error that if you pass an error or something like that, it's just uh invalid argument or invalid return value.

A

Right, good good, uh so the only thing in this whole picture that I think we might decide to question is if a primitive value, if, if something that's passable through the call boundary by a return, if one of those is thrown rather than returned, uh we could decide to propagate the throw.

A

Because that says that we're not trying to censor what kind of flow control happens across the coral boundary we're just trying to censor the values, I'm not advocating that. I think I think the current behavior on that is fine, but it strikes me as the only part of all this. That's questionable.

C

Yeah and I'm wondering if throwing symbols might be somewhat useful for membranes.

A

Well, it's an interesting question.

C

Or throwing actually or throwing a function that lets you get the errors.

A

That's interesting too yeah the throw has to um be. You know.

A

Okay, I'm I'm no longer definitively not advocating this. I'm now on the fence.

B

Yeah, I need to do more research on this.

C

So I mean basically, we all agree that um trying to especially three treats uh error, instances uh that are thrown is a foot gun. um It's something we're not gonna be able to contain. So we should just consider them, like any other objects, that you would try to pass through, callable binary and and throw a generate tighter.

C

um But the open question is what about uh values that would normally be handled through the callable boundary.

B

Yes, I I remember so yeah, I I remember having some issues a while back with the membrane or even trying to do anything in terms of preserving the air on the other side um when using a detachable financial one and it was pain, painful because the errors can be sub-class and what you do in those cases when you subclass an error, and then you throw that error through the member through the the callable boundary in some degree or something similar to that, and it just doesn't work.

B

um So I, um but um but I'm curious about what happened with the function and the symbol and what happened in those cases.

B

Yeah, I think they, the gist of it, is like okay. If they they, if they want to see the errors to be preserved. Okay, I'm throwing an error and I'm putting a message on it. What happened with the stack trades and so on, and then what happened? If I change my code and now I make a a a different or just a by subclass in the arena and now in the subclass, I'm throwing the the intents of the subclass.

B

What happened? What happened there, my code will work, will break like that's the kind of question that we, I think we the content, argument that we should use for them or.

C

An error instance that has a getter for the name and uh messages, and things like that. It like it becomes a big mess.

A

Yeah yeah, the only thing that that's the only thing that provides anything like transparency across the boundary is a membrane built on top of it.

B

And it works pretty well like I can tell you we use that it works pretty well. You're gonna get there with all the details and yeah. It works. Fine.

A

The stack is an interesting um yeah. I don't know how to think about the stack.

B

I don't remember what we did there um jdd did that part. So it's not around today, but um I I believe we cut it out. So you're gonna get the stock only from the point on on the membrane where we throw anywhere, I believe so, but I I just chat with him more about it.

C

I'm curious, if you have a mechanism similar to hours where you capture the stack inside the membrane on one side of the membrane, and then you capture a stack on the other side and then there's some privileged console or output, or something like that. That can stitch things together.

C

Anyway, deviating there.

C

All right, so I guess the summary of that uh issue is no. The implementation shouldn't be allowed to do anything with um uh error.

C

Instances coming from the other side should not even touch them at all, um and it does raise the question of whether we want to allow primitive uh other callable things through so primitive and functions.

C

I suppose we've exhausted the topics.

A

Or they've exhausted us.

A

So adjourning early is also, of course, always welcome.

C

Totally: okay with that, with that I'll stop the recording thank.

A