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

Re: [Public WebGL] Exceptions in WebGL

On Tue, Apr 6, 2010 at 12:52 AM, Gregg Tavares <gman@google.com> wrote:
> 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
>> > ctx.getActiveUniform(null, 0);   // This must be INVALID_VALUE but the
>> > spec
>> > doesn't stay
>> > ctx.getActiveUniform(validProgramFromDifferenceContext, 0);  //
>> > exception or
>> > 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.

I think this should generate INVALID_VALUE. Null is never a valid
value to pass to this function. INVALID_OPERATION may imply that under
different OpenGL state conditions, the given value might sometimes be

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

I think this should generate INVALID_OPERATION. Future revisions of
the WebGL specification will likely support sharing resources between
WebGL contexts. In this case, if the contexts shared resources, the
same program from a different context would be a valid argument to
this call. Therefore the value isn't always invalid, so it should

> ctx.getActiveUniform(deletedProgram, 0);

WebGL should match the C semantics here. I'm not sure based on reading
the glGetActiveUniform man page which is produced. I suspect

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

I'm pretty sure Web IDL and the JavaScript bindings will convert
undefined to NULL and not throw any exception.

> ctx.getActiveUniform(texture, 0);
> This at least is clear. The WebIDL spec requires this to throw a TypeError
> exception



You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: