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

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



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