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

Re: [Public WebGL] a proposal to sort error codes discussions



This sounds reasonable, but I'm concerned that we will need to
completely replicate OpenGL's error checking code in WebGL
implementations, where currently we are able to delegate at least some
of the error checking to OpenGL. To the best of my knowledge the
OpenGL spec doesn't specify which error is produced when there are two
things wrong with the incoming arguments that would result in
different errors. I think our conformance tests would be good enough
if each negative test tested only one error produced from a given
function call. Verifying all combinations of incorrect inputs or
states for every function call will result in a combinatorial
explosion.

-Ken

On Sat, Jun 5, 2010 at 9:08 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
> No replies yet: either I said something stupid (likely!) or I should give some more context:
>
> In the recent thread "Error codes in drawArrays / drawElements" we discussed a conformance test that currently requires a INVALID_OPERATION error to be raised, and it appeared in the discussion that it should rather require INVALID_VALUE. This shows that in situations where both errors could legitimately be raised, it wasn't clear enough which one to prefer raising. My post here can be summarized by saying: in case of ambiguity, prefer raising INVALID_VALUE over raising INVALID_OPERATION.
>
> Cheers,
> Benoit
>
> ----- "Benoit Jacob" <bjacob@mozilla.com> wrote:
>
>> Hi,
>>
>> In order to write conformance tests checking error codes, we must
>> agree precisely on what error codes to produce in every circumstance.
>> Here's a proposal to sort this once and for all.
>>
>> In every WebGL function, let's use the following logic:
>>     1. first check for INVALID_ENUM
>>     2. then check for INVALID_VALUE. Only raise that error if some
>> parameter value is *absolutely* wrong in itself, regardless of other
>> parameters, and regardless of the state.
>>     3. finally, check for INVALID_OPERATION.
>>
>> Adopting such a clear hierarchy between these 3 error codes, will
>> allow to sort out all the ambiguous situations where more than one of
>> these errors could legitimately be produced.
>>
>> Here's a quick rationalization. INVALID_ENUM and INVALID_VALUE mean
>> that a parameter value is absolutely, intrinsically wrong in itself,
>> so they are the most directly useful errors, so they are prioritized
>> over INVALID_OPERATION, which means that parameter values are
>> relatively wrong (relatively to each other or to the state). Between
>> INVALID_ENUM and INVALID_VALUE, let's prioritize INVALID_ENUM, since
>> the GLenum parameters are typically passed compile-time constants.
>>
>> Cheers,
>> Benoit
>> -----------------------------------------------------------
>> You are currently subscribed 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 subscribed 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 subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: