[Public WebGL] Null return values from create*

Glenn Maynard [email protected]
Mon Apr 9 19:21:56 PDT 2012


On Mon, Apr 9, 2012 at 8:39 PM, Kenneth Russell <[email protected]> wrote:

> Early in the development of the WebGL spec, every entry point raised
> DOMException, and exceptions were thrown for various error conditions
> that would be caught by the WebGL implementation, rather than the
> underlying OpenGL API. It was decided some time ago to unify the
> behavior to stop throwing exceptions and instead use OpenGL's error
> reporting mechanism -- synthesizing OpenGL errors where necessary. The
> reasons were that "real" errors in the application would necessarily
> be reported via OpenGL's getError() call; that debug wrappers could
> translate OpenGL errors into JavaScript exceptions anyway; and that
> applications should not need to use try/catch around every GL call in
> order to be robust.
>

This was a serious design error, which disregarded the conventions of the
entire platform.  It's too late to fix this mistake in the general case,
unfortunately.

This isn't relevant here, though.  Making create* return invalidated
objects instead of null doesn't cause TypeError to be raised.  It would
cause the same INVALID_OPERATION to be generated, due to the invalidated
flag rule in the dispatch steps.  There are no drawbacks to this; all it
does is reduce the number of possible branches in user code, and make a set
of bugs impossible.

(Throwing TypeError on programming-error nulls--nulls when nulls are always
invalid--is definitely the right thing to do.  Making functions nullable
when null isn't a valid value to bypass WebIDL's type checking would be
like making every function take "any" arguments so they don't throw if you
pass an incorrect type; it's inconsistent with the platform and provides no
benefit.  However, this is orthogonal to whether create* return null or
invalidated objects.)

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


More information about the public_webgl mailing list