feat: handle interaction error response algorithm

[relu91]

Initial draft of the algorithm to handle interaction error response, as described in issue #560.

Discussions points:

• Introduced the concept of interaction method to indicate one of the methods of Consumed thing that implements a TD operation.
• The mapping between AdditionalExpectedResponse and the actual response is left underspicified to let the protocol binding implementation decide (for example, the HTTP binding might use htv:statusCodeValue to match the right expected response)
• I introduced a dedicated custom error for error responses that match the one declared in the TD. OperationError in the end was too generic, and it didn't allow attaching the response as InteractionOutput as I did with InteractionError
• Given the fact that InteractionOuput take as input a Form we should override its content-type with the one declared in the AdditionalExpectedResponse. This change is not yet in this PR.

---

Preview | Diff

[danielpeintner]

Some very high level comments/questions

• Do we need the concept of "interaction method"? Why can't we use op right away ? I did not quite get that point 🙈
• I think the editors not right before section 8 needs to move up

[relu91]

Do we need the concept of "interaction method"? Why can't we use op right away ? I did not quite get that point

I needed the new definition to quickly reference all the ConsumedThing methods that implement the WoTInterface here:

This algorithm is used by interaction methods to process error responses
from the Protocol Bindings and determine whether to create an
{{InteractionError}} or map to a standard error type.

Ofc, we can remove it if you have better suggestions.

I think the editors note right before section 8 needs to move up

Yes, that is another discussion point: should we keep it?

[egekorkan]

I was initially confused with the standard error type but read further and understood that it means a DOMException. Am I right?

[danielpeintner]

I think @relu91 is hinting at the other errors we are using like NotFoundError, SecurityError, NotSupportedError , SyntaxError ...

Correct?

[relu91]

From today's call:

• In the past, we used https://webidl.spec.whatwg.org/#idl-DOMException-error-names as a basic reference for already defined errors. However, the semantic it is a little bit stretched as the DOMException relates to errors revolving around HTML parsing. As you can see in the document, we found some relevant mappings (NotFoundError, NotAllowedError...) that need to be refactored if we decide to use another error reference. In the future, we should review if it makes sense to continue to use this mapping. @zolkis's opinion would be valuable here.
• Probably we should also cover the ExposedThing side when dealing with AdditionalResponses

I covered the comments and finished referencing the algortihm in relevant section. @danielpeintner and @egekorkan please have a look.

[danielpeintner]

Looks very good. Some comments below.

[danielpeintner]

Suggested change

	The alorithm presented here might be subject to changes in the future.
	The algorithm presented here might be subject to changes in the future.

[danielpeintner]

This sentence reads a bit strange.
What about

Return a new InteractionError constructed with errorOutput. Please ensure the message is appropriately derived from the specific binding or error encountered.

[zolkis]

• In the past, we used https://webidl.spec.whatwg.org/#idl-DOMException-error-names as a basic reference for already defined errors. However, the semantic it is a little bit stretched as the DOMException relates to errors revolving around HTML parsing. As you can see in the document, we found some relevant mappings (NotFoundError, NotAllowedError...) that need to be refactored if we decide to use another error reference. In the future, we should review if it makes sense to continue to use this mapping. @zolkis's opinion would be valuable here.

I can only make non-substantial contributions now (as I am not a group member any more).

The mismatch comes from the fact the Scripting API is a W3C spec, and as such, uses the Infra.
In practice, the implementations are npm based, so a W3C spec is not even needed.
Even more since browser implementations are unlikely (close to 0 probability).
But the spec can override the exception handling, even if it's syntactically a W3C spec -- but then expect issues when someone eventually (theoretically) decides to implement the spec in the browser :) :).

[relu91]

WebIDL suggests extending DOMException, I need to update this before merging, since the discussion (Error vs DOMException is still open.

[relu91]

@danielpeintner turns out that if we want to extend DOMException, the "extra data" we carry in the Exception must be serializable. Sadly, InteractionOutput is not serializable as it contains a non-serializable field ( ReadableStream? data). We can:

• Leave the changes as they are, but we have this inconsistency between the "native" errors and our "custom" error. The inconsistency is that InteractionError does not extend DOMException.
• We force the thrower of the error to eagerly read the full payload and then throw.

[danielpeintner]

It seems easiest to stick with Error since we are not happy with DOMException anyway.