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

Re: [Public WebGL] Exceptions in WebGL





On Tue, Apr 6, 2010 at 6:08 AM, Kenneth Russell <kbr@google.com> wrote:
On Mon, Apr 5, 2010 at 12:23 AM, Gregg Tavares <gman@google.com> wrote:
> Maybe I'm skimming over it but it doesn't appear there is any language in
> the current spec about what WebGL functions should throw an exception and
> under what conditions even though every function is specified has able to
> throw one.
>
> for example.
>
> ctx.getActiveUniform(validProgram, invalidIndex);   exception or
> INVALID_VALUE?
> ctx.getActiveUniform(null, 0);   // This must be INVALID_VALUE but the spec
> doesn't stay
> ctx.getActiveUniform(validProgramFromDifferenceContext, 0);  // exception or
> INVALID_VALUE
> ctx.getActiveUniform(deletedProgram, 0);  // exception or INVALID_VALUE?
> ctx.getActiveUniform(undefined, 0);  // exception or INVALID_VALUE?
> ctx.getActiveUniform(texture, 0);  // exception or INVALID_OPERATION
>
> Pretty much every function has the same issues.
>
> Should this be nailed down? Am I just missing the section that covers it?

Earlier in the development of the WebGL spec it wasn't well defined
which sorts of invalid inputs throw exceptions and which synthesize
OpenGL errors. A few months ago after much discussion it was decided
that the error handling would be unified to always synthesize OpenGL
errors, and not throw exceptions. This unifies the error handling
behavior and makes it easier to write things like debug GL wrappers
which turn OpenGL errors into exceptions.

The fact that the IDL still states that all of the entry points raise
DOMException is basically an artifact. The best explanation for why
this hasn't changed is so that the option is available in the future
to throw DOMException if necessary.

Some of the situations above (where you're passing an object of the
wrong type) should be defined by Web IDL, I think, and should throw a
SYNTAX_ERR DOMException. However, if the call makes it through the
_javascript_ binding, it should never throw an exception.

-Ken


Sounds good.

So that still brings up the question of what specific errors to synthesize and adding these to the docs.  For example.

ctx.getActiveUniform(null, 0);  
 
This seems like it should generate INVALID_VALUE but some might argue for INVALID_OPERATION.  The argument for INVALID_VALUE is that's what the C api would generate for an unknown value. The C api only generates INVALID_OPERATION when the value passed in for program is something other than a program. In WebGL that would raise an exception that a non-WebGLProgram object was passed as the first parameter. On the other hand, we know his is an invalid operation.

ctx.getActiveUniform(validProgramFromDifferenceContext, 0); 

This one as well, INVALID_VALUE or INVALID_OPERATION.  In the C api, again, an unknown value would generate INVALID_VALUE and only passing in the ID of something not a program would generate INVALID_OPERATION. On the other hand, we know that it's an invalid operation to use a program from a different context.

ctx.getActiveUniform(deletedProgram, 0); 

Same question. INVALID_OPERATION or INVALID_VALUE

ctx.getActiveUniform(undefined, 0); 

It's not clear to me if undefined converts to a value and should therefore generate an error or undefined is marked at the WebIDL level as an exception. 

ctx.getActiveUniform(texture, 0); 

This at least is clear. The WebIDL spec requires this to throw a TypeError exception