[whatwg] Canvas.getContext error handling

[Glenn Maynard]

To confirm the fundamental problem: Canvas.getContext (and the corresponding
"Return a new object for *contextId*" algorithm) can never return null.

   http://krijnhoetmer.nl/irc-logs/whatwg/20110412#l-209

It's intended that calling getContext on a supported context *always* return
a context; it never returns null and it never throws an exception.

Now, that's a problem for WebGL, because it's not possible to tell in
advance whether the underlying rendering context can be created.  I'm not
sure what the correct fix is, but the current status quo is that the HTML
Canvas and the WebGL specs are in conflict; something needs to change to
bring them together.

It would be helpful if someone involved in editing the WebGL spec would
discuss this on whatwg to figure out how to do that.

On Sat, Apr 9, 2011 at 11:26 PM, Cedric Vivier <cedricv at neonux.com> wrote:
> IIRC another reason we used an event is to allow the application to be
> notified when context restoration failed (see webglcontextlost event).

That's webglcontextlost, though, not webglcontextcreationerror.

On Mon, Apr 11, 2011 at 8:55 PM, Kenneth Russell <kbr at google.com> wrote:

> Just for the record, I'm sure the WebGL working group would be
> amenable to making changes in this area. However, there is a general
> problem: if getContext() throws an exception, how does the caller know
> whether a later call to getContext() might succeed, or will always
> fail?
>

You don't, though that question arises regardless of whether you're using an
exception or an event.  Maybe it's useful to tell the application whether
the error is permanent or not, but I'm not proposing that here.

I don't remember all of the discussions in the WebGL working group
> which led to the currently defined behavior, but I think that the fact
> that 3D graphics contexts can be spontaneously lost, and recovered,
> factored into the current design.
>

It looks like an attempt to report all errors in the same way.  I don't
think that's the right approach.  Web APIs make a distinction between async
and sync errors.  getContext failing to create a context is a synchronous
error; those are reported with exceptions.  A context being lost is an
asynchronous error; those use events..

-- 
Glenn Maynard