[Public WebGL] Null return values from create*

Glenn Maynard [email protected]
Thu Apr 5 17:33:43 PDT 2012

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/19ec57bd/attachment.html>

More information about the public_webgl mailing list