It seems like the expectation was that null returns would work implicitly, without the caller needing to check for null. That mostly works for things like WebGLTexture, which has no methods and is only passed to functions which accept null. However, it doesn't seem like this holds consistently throughout all affected API calls.
It works for WebGLTexture unless you do this
tex = gl.createTexture();
tex.url = "">
The cases I had in mind were eg. accessing tex.__proto__, or code which uses "tex instanceof WebGLTexture". Your example is more common, though.
This category is less problematic than those above, but it could be improved pretty easily. For methods returning WebGLTexture and other "resource objects", instead of returning
null, return a WebGLTexture which is already invalidated, in the
same way that existing textures are invalidated when the context is
lost.
I'm not sure what the right thing to do would be, though. Throwing an exception would be an improvement, at least.
No that would be just as a bad if not worse.
I think it's a straightforward improvement, for the cases where returning null breaks code. It doesn't make code work automatically, but it makes writing correct code a lot less painful, in the usual sense of being able to put error checking in an exception handler instead of sprinkling null checks all over the place.
Ideally, each function would return something that is unlikely to break code. We can either change the spec or add some examples (or a link to examples) showing the correct usages. Something like this
with more examples added for getVertexAttrib etc.
Returning a placeholder value on error (zero, false, arrays filled with zeroes, and so on) rather than null would make user code more likely to tolerate it until it can receive the webglcontextlost event, and you could check whether a return value is an error by calling isContextLost at the end of an operation. Defining error case returns for everything would be a lot of surface area in the spec, though, and it sort of turns error values into a bunch of special cases.
I don't think just having a bunch of examples on a wiki is a good solution, though. Few enough people even handle the context loss event, without expecting them to deal with this.