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

Re: [Public WebGL] Null return values from create*

> There are no performance issues with using exceptions for synchronous errors like these.
Not true - try/catch deoptimizes every JIT - a simple if (!result) {} is significantly faster and results in smaller _javascript_ code size (as the variable can be renamed - 'try' and 'catch' cannot be).

Exception handling should be reserved for exceptional situations. Proposing that getParameter & co throw an exception is absolutely revolting to me - it does the *exact opposite* of making code robust and easy to write against. For example, exceptions are impossible to ignore without writing code to try/catch-and-pass - pollable errors are trivial. You also *must* ensure every potentially throwable function is guarded or has defined behavior, otherwise you end up with bad state or exceptions that bubble up well beyond their call-site. Not to mention the inconsistencies with getError (that cannot go away due to async calls, as you point out) and this - one would have to memorize which functions did what, adding to the confusion and possibility of missing a try/catch.

From someone who has worked with large amounts of shipping, high-quality code written against the current WebGL behavior: the current model works well. Let's not change something that is not broken and actually has many advantages vs. the alternatives.

On Thu, Apr 5, 2012 at 5:33 PM, Glenn Maynard <glenn@zewt.org> wrote:
On Thu, Apr 5, 2012 at 7:11 PM, Gregg Tavares (勤) <gman@google.com> wrote:
Wait what? How would exceptions help here? Is it even possible to use exceptions AND get performance AND get no surprises during context lost? 

There are no performance issues with using exceptions for synchronous errors like these.  The usual problem with exceptions is for *asynchronous* errors--ones that can't be detected before the function returns without forcing a glFinish(), and can only be checked with getError.  That is, having stencilFunc throw an exception would cause a performance problem, because you'd have to wait for the action that the function queues to complete before returning.  For functions like getParameter and getProgramInfoLog, you already have to wait for it to finish in order to know what to return.

With exceptions, the rare context-lost error cases are a lot easier for users to handle reliably.  Problems can still crop up--you still have to test your exception handling--but it's a huge improvement over C-style return-value error handling.

(Again, just to be clear, exceptions don't replace getError.  getError is useful for asynchronous errors--errors where the error may not actually happen until after the function returns.  We're only talking about synchronous errors here: errors that are always detectable before the function returns.  All errors that can be reported with a null return value can be reported with an exception, without affecting performance.  If anything, it improves performance, by taking "if(x == null)" checks out of the main body of _javascript_ code and replacing them with an out-of-line exception handler.)

It's probably much too late for anything like this, since it'd be a breaking change.  (I suppose it could be an extension, that when loaded, changes dispatch step 6.2 from "return null" to "throw an exception".  I'd be sort of afraid of an extension like that segmenting WebGL libraries into two groups, though--ones that only work with the extension and ones that only work without it.)

Glenn Maynard