[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 22:59, Glenn Maynard <glenn@zewt.org> wrote:
> 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.

Agreed, I was just pointing out that the stated advantage of not
having to specify context-specific information is pretty much
non-existent then.

> 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.

That WebGL is not supported _right now_ and cannot be used by the
application is already conveyed by null.
The fact that it is a temporary error - because of one of many
potential reasons - is more of an implementation detail on some
platforms/browsers, that should not matter to the applications.

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 didn't have luck convincing upstream to add an
> exception path for getContext, but I'd expect much stronger resistance to
> using an event.

Yes I've seen that iirc and I certainly understand their concerns.
On the other hand, the event is already what we have and is
independent from the Canvas spec (it does not forbid it), so no
resistance to fight here.
Also, events will possibly be what we use in the future if we go the
asynchronous way you've proposed.

>> 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 [1].
> Debuggers shouldn't be breaking on exceptions that are caught anyway, or
> they'll have tons of false positives.

Yet that's what they do (not limited to JS dev tools)... and
developers don't run into tons of false positives because exceptions
in JS do happen primarily because of wrong API usage (edit-time)
rather than temporary failure (run-time).


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