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

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



That's a good point... I think that we do need tests that specify multiple incorrect arguments, and they should just check that /some/ error is produced (or perhaps they can check for "INVALID_VALUE or INVALID_ENUM", depending no what they're checking).  So maybe we just write tests in that form and not mandate a specific error reporting order.

    - Vlad

----- "Kenneth Russell" <kbr@google.com> wrote:

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

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