- From: Kenneth Russell <kbr@google.com>
- Date: Mon, 11 Apr 2011 17:55:51 -0700
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 fail? 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. -Ken
Received on Monday, 11 April 2011 17:55:51 UTC