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

Re: [Public WebGL] Exceptions in WebGL



Thanks for the patch. Applied.

-Ken

On Thu, May 6, 2010 at 6:53 AM, Cedric Vivier <cedricv@neonux.com> wrote:
> Resurrecting this thread to propose spec patch [1] to act on what
> (seems to) have been agreed upon :
> - use verb "generate" instead of "raise" for GL errors (not exceptions)
>
> Additionally :
> - for visual/semantic consistency, always use <code> with error names
>
>
> Cheers,
>
> [1] : http://neonux.com/webgl/errors-cleanup.patch.txt
>
>
> On Thu, Apr 8, 2010 at 02:45, Kenneth Russell <kbr@google.com> wrote:
>> 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
>>>> > 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.
>>
>> 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
>> valid.
>>
>>> 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
>> produce INVALID_OPERATION instead of INVALID_VALUE.
>>
>>> ctx.getActiveUniform(deletedProgram, 0);
>>>
>>> Same question. INVALID_OPERATION or INVALID_VALUE
>>
>> WebGL should match the C semantics here. I'm not sure based on reading
>> the glGetActiveUniform man page which is produced. I suspect
>> 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.
>>
>> 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
>>
>> Agreed.
>>
>> -Ken
>>
>> -----------------------------------------------------------
>> 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:
>>
>>
>
> -----------------------------------------------------------
> 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:
>
>

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