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

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



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: