[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] (summarizing) Canvas.getContext error handling
On Fri, Apr 29, 2011 at 11:24 AM, Cedric Vivier <email@example.com> wrote:
On Fri, Apr 29, 2011 at 20:08, Benoit Jacob <firstname.lastname@example.org> wrote:
> ** Exceptions are a single unified mechanism; while with theThis argument implies the Canvas spec defines an exception object that
> webglcontextcreationerror way, every new canvas context type will have to
> introduce its own event type.
works for every potential new canvas context type.
Otherwise, every new canvas context type would still have to define
the exception object it throws.
Canvas can just declare a base exception that getContext throws, I think.Â Contexts would throw exception types that implement it, adding any context-specific information.
Exceptions have a strong advantage: they're the ordinary,
established method of reporting errors in synchronous functions.Â Events
are used for reporting errors in async functions.Â I didn't have luck convincing upstream to add an exception path for getContext, but I'd expect much stronger resistance to using an event.
One advantage of an event over an exception is that it does not
interfere with debugging tools (eg. "break on error") - just to pass
to the application mere "additional information" that it might not
even want/need and should be used for debugging purposes only .
Debuggers shouldn't be breaking on exceptions that are caught anyway, or they'll have tons of false positives.