Improve brand check

[katelynsills]

improves the situation described in #990. We still cannot see the allegedBrand name, because the brands may be presences

[Chris-Hibbert]

Looks good. One minor suggestion for clarifying the error message.

[Chris-Hibbert]

You have both brands. Can you print them? When I was debugging, this kind of thing has been very helpful.

[katelynsills]

There's nothing to print. They are objects with a method (which we cannot access) and no properties.

[Chris-Hibbert]

Don't they have getAllegedName()? That's enough to be useful.

[katelynsills]

Yes, but the brand will likely be remote, so we can't call it

[Chris-Hibbert]

That's too bad.

Any chance we can cheat and include the objects so the caller could catch the error and display it themselves? For once, it might be useful to include the opaque object in an error.

[erights]

Please don't pass access by throw. When you throw something, you know very little about who might catch it.

In any case, if you include the brands as substitution holes, e.g.

details`the brand in the allegedAmount in 'coerce' didn't match the amountMath brand: ${brand} vs ${allegedBrand}`,

this will throw an error with the message

`the brand in the allegedAmount in 'coerce' didn't match the amountMath brand: (an object) vs (an object)
See console for error data.`

This avoids even sending the stringification of these substitution values to the catcher by default, under the default assumption that we're willing to reveal the literal part of the details template literal, but only the typeof of their substitution value.

OTOH, to the console, we send the actual substitution values themselves, not a mere stringification of them. If you are in the privileged position of receiving what is sent to the console, for example because you provided the console, then you can receive these values directly. For these purposes, we consider this to be loosely equivalent to the privilege level of viewing the computation through a debugger.

Attn @michaelfig and I are working towards a reform in the distributed object system so that presences can carry description strings which will show up in the default builtin console behavior. So to see that, you merely need access to the textual output of the normal console, which is still a debug level of privilege.

[Chris-Hibbert]

@erights, I read what you said above as indicating that stringifying the brands would be useless, and that including the objects would make them accessible to print on the console. OTOH, you also said they shouldn't be conveyed by a throw.
That sounds like including the objects in the details object would satisfy both objectives, since the console gets access to details, but obfuscates the values in the thrown message.
Am I misunderstanding?

[katelynsills]

Putting brand objects in details will not show anything useful currently. It will show something like { getAllegedName } (non-presence) or { } (presence)

[erights]

LGTM

[erights]

Please don't pass access by throw. When you throw something, you know very little about who might catch it.

In any case, if you include the brands as substitution holes, e.g.

details`the brand in the allegedAmount in 'coerce' didn't match the amountMath brand: ${brand} vs ${allegedBrand}`,

this will throw an error with the message

`the brand in the allegedAmount in 'coerce' didn't match the amountMath brand: (an object) vs (an object)
See console for error data.`

This avoids even sending the stringification of these substitution values to the catcher by default, under the default assumption that we're willing to reveal the literal part of the details template literal, but only the typeof of their substitution value.

OTOH, to the console, we send the actual substitution values themselves, not a mere stringification of them. If you are in the privileged position of receiving what is sent to the console, for example because you provided the console, then you can receive these values directly. For these purposes, we consider this to be loosely equivalent to the privilege level of viewing the computation through a debugger.

Attn @michaelfig and I are working towards a reform in the distributed object system so that presences can carry description strings which will show up in the default builtin console behavior. So to see that, you merely need access to the textual output of the normal console, which is still a debug level of privilege.

[erights]

Above, where I say

Please don't pass access by throw. When you throw something, you know very little about who might catch it.

I'm not responding to the code. The code already doesn't do this. I'm responding to @Chris-Hibbert 's comment in that conversation.

[erights]

See #804

[DavidBruant]

Thanks @katelynsills for this PR and the investigation for improving the error message!

I approve the Pull Request, but i do not consider it solves #990 because the error message remains generic
I acknowledge the current technical limitation prevents a better solution in the short term

[katelynsills]

I think this is ok to merge into master since from the user's perspective, all that changes is a single error message which was not documented anywhere. It's also an ERTP issue and not a Zoe issue so doesn't quite fit into Zoe v0.6.0