[Public WebGL] Null return values from create*

Gregg Tavares (勤) [email protected]
Thu Apr 5 17:55:17 PDT 2012

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

I'm still not sure what you are suggesting. That calling any function
during context lost throws an exception? that sounds far more surprising to
me than returning NULL.

The whole point of returning and accepting NULL is that with a few simple
rules you have do nothing special during context lost. All the code will
just keep running but doing nothing. If every create threw an exception now
you'd have to have all kinds of special cases to handle every place you
call createXXX. I don't see how that's a win.

> --
> Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120405/32941829/attachment.html>

More information about the public_webgl mailing list