[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Exceptions in WebGL
- To: public webgl <email@example.com>
- Subject: Re: [Public WebGL] Exceptions in WebGL
- From: Cedric Vivier <firstname.lastname@example.org>
- Date: Thu, 6 May 2010 21:53:16 +0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; bh=us1rSAnw1jfl6nVPL2m38kCfP9EKc7BY/wkNN5yxsUE=; b=Sl38GCvERCg3qlGUOouacqUn1ryjlntx8lQFqqacI45ISI5RZbf1cgbSYfZczIxPKs gSfUBugkS4pIAiSVfNZQek/HuiY4sz4bY1f7rNSq4HWeLEAbQplpmP1aV2FHCrctDKGu bhfL6u7Z+Ns4R6A1QgFC7M9P5QlvhTh2C+dAA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=UiiDRjK74OPIBxuya8ljka9ZkmgfhbdsM3XKXgGtDeEuAo4i6cqlhaF7WkFJPHEFsV wN1CZgYHHmjD/COdBiTjcJKrVa1h2v/um48d9krhh71UVz14/w5BW5OUSUtD3y37uBmq FXR6vxpYx9NiiBmlPIEGtXIMQW0EkZc2HKpo0=
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
- Sender: firstname.lastname@example.org
Resurrecting this thread to propose spec patch  to act on what
(seems to) have been agreed upon :
- use verb "generate" instead of "raise" for GL errors (not exceptions)
- for visual/semantic consistency, always use <code> with error names
 : http://neonux.com/webgl/errors-cleanup.patch.txt
On Thu, Apr 8, 2010 at 02:45, Kenneth Russell <email@example.com> wrote:
> On Tue, Apr 6, 2010 at 12:52 AM, Gregg Tavares <firstname.lastname@example.org> wrote:
>> On Tue, Apr 6, 2010 at 6:08 AM, Kenneth Russell <email@example.com> wrote:
>>> On Mon, Apr 5, 2010 at 12:23 AM, Gregg Tavares <firstname.lastname@example.org> 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
>> 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
>> 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
> 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
>> 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
> 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
> You are currently subscribe to email@example.com.
> To unsubscribe, send an email to firstname.lastname@example.org with
> the following command in the body of your email:
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: