[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 12:29 PM, Cedric Vivier <cvivier@mozilla.com> wrote:
Agreed, I was just pointing out that the stated advantage of not
having to specify context-specific information is pretty much
non-existent then.

A generic event.message isn't context-specific, and could go in the base exception (with the stipulation that it may be empty).

Â
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'm not the one pushing to keep diagnostic messages around. :)

That said, while web developers shouldn't be *forced* to handle these errors, it's entirely different to *allow* them to do so. If I'm releasing a commercial game using WebGL, I *want* to be able to support my users. It's certainly better when I don't have to, but there are points between "only the browser can provide troubleshooting at all" and "the application developer is forced to do everything".

An aside: It's definitely good if browsers can offer help for known problems. For example, if your video drivers are known to be too old for WebGL, but newer video drivers are available which will work, showing a "you should update your video drivers to make WebGL work, click here for more info" box could be a big help. That's definitely the browser's job and not job of each web page.

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. What if WebGL is used by an optional, secondary feature? I may prefer to simply disable it if it fails. (If using WebGL causes some percentage of users who might have purchased something on a page to instead go off and download video drivers--and forget that they were about to buy something--then that would be a deterrent to using WebGL entirely.)



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

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

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

It's normal for APIs to throw exceptions based on runtime errors. Design the API properly and debuggers will catch up quickly enough. Debuggers advance over time, but once an API is out there we're stuck with it forever.

There aren't so many of these yet because most runtime errors in _javascript_ APIs are asynchronous. You'll be seeing more use of traditional exceptions in the future, since the existance of Web Workers means synchronous APIs make more sense. For example, FileReaderSync methods throw on read errors. Web Storage has QUOTA_EXCEEDED_ERR, too.

--
Glenn Maynard