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

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



I don't have a problem with that, I think I agree with you but am a bit too new here to make that kind of decision; but if we go this path, the existing conformance tests must be patched to avoid requiring one particular error code in situations where more than one are legitimate. I'm waiting for a green light here to start doing so.

Benoit

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