I don't think that's true. If someone passes "asdf" to the CanvasFilter constructor, changing from not-throwing to throwing would be a breaking change. We'd need to add use counters, etc. to find out if anyone is passing such invalid values.
Whereas, if we start off with throwing, we can always remove the throwing behavior later, with no use counters required. On Fri, Oct 29, 2021 at 1:43 PM Fernando Serboncini <fs...@chromium.org> wrote: > Since the current implementation is not throwing, we could reasonably > launch as-is and the add throwing if it is agreed to do so after. > The added risk is the exact same risk that we are arguing to begin with > (i.e., code that uses not-implemented filters without try/catch would > break). But since there are no "not-implemented filters" yet, it may not be > a problem. > > On Fri, Oct 29, 2021 at 1:34 PM Domenic Denicola <dome...@chromium.org> > wrote: > >> Yep. Reasonable people can disagree on the tradeoffs here. The question >> is whether this is something we want to deadlock over with other >> implementers. >> >> On Fri, Oct 29, 2021 at 12:28 PM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> On 10/29/21 1:23 AM, Yoav Weiss wrote: >>> >>> Hey Domenic! :) >>> >>> On Thu, Oct 28, 2021 at 11:00 PM Domenic Denicola <dome...@chromium.org> >>> wrote: >>> >>>> >>>> FWIW the two HTML editors on the thread (myself and Anne, with our HTML >>>> editor hats on), as well as Mozilla (via Anne with his Mozilla hat on), >>>> prefer the throwing behavior. I think in most cases to overcome that >>>> position we would need some really strong reasons why the Chromium project >>>> believes the non-throwing behavior is better. It's not clear to me how >>>> strong Chromium's position is on this issue, and whether it's worth >>>> delaying the feature over. (Or indeed, delaying all the features, since the >>>> plan seems to be to bundle them together?) >>>> >>> >>> My concerns with the throwing behavior are similar to the ones we have >>> discussed >>> <https://github.com/w3c/mediasession/issues/228#issuecomment-886455386> >>> in the context of MediaSession actions. >>> If we go with the throwing behavior, every future addition of filters >>> would have a significant interop risk, in case adopting developers won't >>> use try/catch properly. If they do that and they are not testing in >>> not-yet-supporting browsers, their apps are likely to break entirely in >>> those browsers. >>> If we go with a silent failure + feature detection approach, developers >>> using the feature without properly detecting it may not have the desired >>> visual effects they are going for, but won't have unrelated parts of their >>> app break. >>> >>> From my perspective (with my API owner hat on), less risk is better, and >>> the second approach seems less risky to me. >>> >>> I agree with Yoav here (sorry, I don't own any hats). Not throwing will >>> likely result in fewer broken pages in less-well-tested browsers that >>> haven't implemented the APIs yet. And +1 for devtools warnings to help >>> developers figure out "silent" failures. >>> >>> (I also wonder if requiring try/catch won't trip up new developers >>> trying to use it inside Promises, who don't yet know about `then()/catch()` >>> patterns). >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8qHDKH0XzaxWSVVmhwfwtGgTCg-6%3D-pjt656frMZscSA%40mail.gmail.com.
