Re: [whatwg/webidl] Handle exceptions when calling callbacks by default (Issue #1423)

> > canvas toBlob
> 
> This needs to catch and report, I think? Right now the error just goes to the top level of the task, which is... undefined behavior?

Agreed, it should probably report. Updated the table.

> > It's likely that the callback's realm's global is appropriate, though for each a cursory check of existing browser behavior would be nice.
> 
> I'd really like us to be able to use the same answer for all cases and not have this be configurable per call site. But yeah, agreed that a check would be good.

Agreed, though if that is not what browsers do then we have to get vendors to change it, assuming doing so would be web-compatible. I'm hoping that it's either already doing that everywhere or it's easy to fix.

> > Do you still think this should be a boolean defaulting to reporting, or should this be a required parameter? Or maybe some kind of conditionally required parameter, where it must be specified unless it's a promise-returning callback?
> 
> I hadn't thought a conditionally-required parameter before. Maybe that's the way to go, if we're changing all the call sites anyway.
> 
> Reporting-by-default makes "invoke" and friends require fewer brains to use; if you told me there was a Web IDL algorithm called "invoke" for callbacks I might just call it without thinking to look up if it had extra arguments. But if we can assume that all spec writers look up the signatures of the algorithms they use, then probably it's better. And I think that's a ... reasonable? ... assumption.
> 
> In that case I'd change from a boolean to something like "report" vs. "rethrow".
> 
> I was wondering if we could do "report-and-rethrow" for the cases that report but also do custom behavior. But I feel like probably in those cases you want to do the custom behavior first, before potentially running author code? (Although at least [one place](https://dom.spec.whatwg.org/#concept-create-element) does not do that right now... I wonder if that's a bug.) I don't know; if there were a way to make it easier to ensure that people always send it to the right global for a callback after doing their custom processing, that would be nice. Let me know if you have an yideas.

There are few enough sites and they're special enough already that I think complicating WebIDL to handle them is probably not worthwhile. And hopefully the number of such sites doesn't grow too much.

> For how to do "conditionally-required", I'd do something like
> 
> > To invoke a callback function type value _callable_ with a Web IDL arguments list _args_, exception behavior _exceptionBehavior_, and an optional callback this value _thisArg_, perform the following steps. These steps will either return an IDL value or throw an exception. The _exceptionBehavior_ argument must be supplied if and only if _callable_'s return type is not a promise type.
> 
> The other strategy I thought of was declaring it as optional with a default of "promise", and then using an Assert to state that it's not left as the default for non-promise _callable_s. However, this has the disadvantage that someone skimming the algorithm declaration might think it was actually optional.

I had those exact same two thoughts and typed both of them in a response before noticing you'd described exactly the same things.

(also, bikeshed: _exceptionBehavior_ vs _exceptionHandling_?)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1423#issuecomment-2260702222
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1423/2260702222@github.com>