Re: [w3c/webcomponents] Should innerHTML propagate custom element constructor exceptions? (#525)

There could be multiple exceptions; propagating up to one seems arbitrary.
Authors should follow the Pokemon trainer principle: if you're interested
in exceptions, you should use onerror to catch 'em all.
On Jun 21, 2016 4:28 AM, "Domenic Denicola" <notifications@github.com>
wrote:

> As currently specced, innerHTML uses the HTML parser. If element creation
> throws an exception in the HTML parser, we report the exception
> (window.onerror etc.) instead of propagating the exception, because
> normally when using the parser there is nowhere to propagate it to.
>
> This is certainly easiest to spec, but seems like it might be against the
> original intent. That is, I would kind of expect this to catch the
> exception:
>
> customElements.define("x-foo", class extends HTMLElement {
>   constructor() {
>     throw new Error("boo");
>   }
> });
> try {
>   document.body.innerHTML = "<x-foo></x-foo>";
> } catch (e) {
>   // do we get here?
> }
>
> If we did want this to propagate the exception, I'm not sure the best way
> to spec it... we can't just say "in the fragment case, propagate the
> exception" since the fragment case is also used in other places that aren't
> DOM APIs. We could cheat and say something like "if the JS execution
> context stack is not empty, propagate the exception" but I might imagine
> stack inspection is not desirable for implementers? Otherwise I guess we
> could explicitly set a flag...
>
> /cc @rniwa <https://github.com/rniwa> @dominiccooney
> <https://github.com/dominiccooney> @kojiishi <https://github.com/kojiishi>
> @annevk <https://github.com/annevk>
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/webcomponents/issues/525>, or mute the thread
> <https://github.com/notifications/unsubscribe/AADXUBasbm-SLxsWyW47y7nDNCdiGmvxks5qNunVgaJpZM4I6CiB>
> .
>


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/525#issuecomment-227293796