[Public WebGL] Null return values from create*

Ben Vanik [email protected]
Thu Apr 5 18:00:30 PDT 2012

> 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 <[email protected]> wrote:

> On Thu, Apr 5, 2012 at 7:11 PM, Gregg Tavares (勤) <[email protected]> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120405/f76f51cf/attachment.html>

More information about the public_webgl mailing list