W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

[whatwg] Canvas.getContext error handling

From: Kenneth Russell <kbr@google.com>
Date: Mon, 11 Apr 2011 17:55:51 -0700
Message-ID: <BANLkTimGSvfuk36Qja+S=NdUCcxXoO-NVg@mail.gmail.com>
On Sat, Apr 9, 2011 at 7:55 PM, Glenn Maynard <glenn at zewt.org> wrote:
> getContext doesn't specify error handling. ?WebGL solves this oddly: if an
> error occurs, it dispatches an event with error details at the canvas. ?It's
> odd for a synchronous API to report error information with an event; it
> would make a lot more sense to raise an exception. ?However, getContext
> doesn't specify error handling for the "Return a new object for contextId"
> algorithms.
> The "primary context" should only be set by getContext after "Return a new
> object for contextId" completes successfully; it shouldn't be set on error.
> The cached return value used in step 5 should also only happen after
> success; don't cache a null response. ?This way, you can retry getContext on
> failure, and getContext is a straightforward no-op after an error.
> (I don't know if the WebGL folks could be convinced to change to throwing an
> exception or if they want to continue returning null and firing an event.)
> Related thread:
> https://www.khronos.org/webgl/public-mailing-list/archives/1104/msg00027.html

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

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.

Received on Monday, 11 April 2011 17:55:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:05 UTC