[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] (summarizing) Canvas.getContext error handling



On Sat, Apr 30, 2011 at 00:55, Glenn Maynard <glenn@zewt.org> wrote:
>> Do you agree that we should not push the trouble of troubleshooting
>> (and troubleshooting UI) to application developers?
>> The browser can do much better at it.
>
> I'm not the one pushing to keep diagnostic messages around. :)

I think we both agree on that ;)
However, for now, we are trying to reconcile Canvas spec and WebGL
spec as part of a minor revision.


> That said, while web developers shouldn't be *forced* to handle these
> errors, it's entirely different to *allow* them to do so.

Conceptually, an exception *forces* all developers to handle errors
through a catch block.
An event *allows* only if the developer chooses to.


> However, how does the browser know when it's appropriate to show this? If
> my page is a game and I have no fallback, then I probably do want this. But
> what if I have a 2d fallback? I (the application developer) may want to
> simply use it and not distract the user with video driver diagnostics.

On top of my head, this could possibly be handled through an
unobstrusive UI (geolocation API style) with :
_
This web page failed to initialize WebGL [Upgrade my drivers] [Not
now] [Forget about it]
_


Your use case is doubly interesting as it shows how throwing an
exception would force to developers quite a bit of
verbosity/indentation to handle multiple fallbacks compared to only
handling null...

As code examples are worth 1000 words, consider :

try {
    ctx = getContext("webgl-2.0")
    if (!ctx) { /* webgl-2.0 is not supported _at all_ */
         throw "dummy exception to avoid multiple function calls that
would make this example even more verbose";
    }
    return initializeWebGL2(ctx);
} catch (e) { /* webgl-2.0 is not supported _right now_ */
    try {
         ctx = getContext("webgl")
         if (!ctx) { /* webgl is not supported _at all_ */
             throw "dummy exception to avoid multiple function calls
that would make this example even more verbose";
         }
         return initializeWebGL(ctx);
    } catch (e) { /* webgl is not supported _right now_ */
         ctx = getContext("2d") // oh well for this context we do not
need a try/catch at least...
         if (!ctx) { /* 2d is not supported _al all_ */
              unsupportedBrowser();
         }
         return initialize2D(ctx);
    }
}

VS

ctx = getContext("webgl-2.0");
if (ctx) {
     return initializeWebGL2(ctx);
}
ctx = getContext("webgl"); /* webgl-2.0 was not supported (at all or
right now, we do not really care) */
if (ctx) {
     return initializeWebGL(ctx);
}
ctx = getContext("2d"); /* webgl was not supported (at all or right
now, we do not really care) */
if (ctx) {
     return initialize2D(ctx);
}
unsupportedBrowser();



> It's awkward to spec "dispatch an event and return null" with the current
> getContext spec. That should be done from step 2 of getContext ("If
> contextId is not the name of ..."), and it'd be unnatural to have a
> definition that looks like: "when required to determine if contextId is the
> name of a context supported by the user agent, create the underlying
> context; if it fails, dispatch an event and return false from this
> algorithm".

An application is notified that a context is not supported by returning null.
The Canvas spec needs a minimal change equivalent of adding "or not
supported _right now_" to the statement above.

getContext spec does not have to even talk about the event at all :

> Whether using events or exceptions, it would be much clearer if
> getContext was adjusted--right now WebGL is essentially wedging error
> handling into a function not designed for it.

webglcontextcreationerror _is not_ an error-handling mechanism, it is
an opt-in mechanism to convey additional debugging/error information
only if desired.


For all these reasons, I believe throwing an exception changes 1.0
semantics for little benefit if any whereas it adds some clear
disadvantages (debugging experience, verbosity, goes against the
principle of least surprise).


Regards,

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------