Bug 93952 – Remove custom bindings from ConvolverNode.idl

• Component: New Bugs
• Status: RESOLVED FIXED

[Vineet Chaudhary (vineetc)]

We should remove custom bindings as CodeGenerator uses UNUSED_PARAM macro.
This was introduced in r72838.

[Vineet Chaudhary (vineetc)]

Created attachment 158284 [details]
Patch

Actually I was planning to remove custom bindings from AudioBufferSourceNode.idl to but I couldn't find a way to throw exception from AudioBufferSourceNode::setBuffer() in AudioBufferSourceNode.cpp for both JSC and V8. 
Is there any way to throw TypeError in common both for JSC and V8?

[Kentaro Hara]

(In reply to comment #1)
> Actually I was planning to remove custom bindings from AudioBufferSourceNode.idl to but I couldn't find a way to throw exception from AudioBufferSourceNode::setBuffer() in AudioBufferSourceNode.cpp for both JSC and V8. 
> Is there any way to throw TypeError in common both for JSC and V8?

No. If you could throw TypeError from WebCore, binding layer has to catch the error and rethrow it to JavaScript, which means that you cannot avoid handling error in the binding layer anyway.

[Kentaro Hara]

Comment on attachment 158284 [details]
Patch

OK

[Vineet Chaudhary (vineetc)]

(In reply to comment #2)
> (In reply to comment #1)
> > Actually I was planning to remove custom bindings from AudioBufferSourceNode.idl to but I couldn't find a way to throw exception from AudioBufferSourceNode::setBuffer() in AudioBufferSourceNode.cpp for both JSC and V8. 
> > Is there any way to throw TypeError in common both for JSC and V8?
> 
> No. If you could throw TypeError from WebCore, binding layer has to catch the error and rethrow it to JavaScript, which means that you cannot avoid handling error in the binding layer anyway.

Ohh thanks I got it. For that we can use ExceptionCode enum.
So we may use INVALID_ACCESS_ERR for TypeError.

But again we have different TypeError messages here like "Value is not of type AudioBuffer" and "AudioBuffer unsupported number of channels" too :(.

[Kentaro Hara]

(In reply to comment #4)
> Ohh thanks I got it. For that we can use ExceptionCode enum.
> So we may use INVALID_ACCESS_ERR for TypeError.

Actually ExceptionCode is not for JavaScript errors but for DOM exceptions. We don't want to mix them just for auto-generating code.

But if we can remove a bunch of custom bindings by introducing something like that, it might be worth considering. It would depend on the benefit.

> But again we have different TypeError messages here like "Value is not of type AudioBuffer" and "AudioBuffer unsupported number of channels" too :(.

Yeah. My point is that "given that the binding layer has to handle the error anyway, let's handle it straightforwardly in the binding layer even if we use custom bindings".

[WebKit Review Bot]

Comment on attachment 158284 [details]
Patch

Clearing flags on attachment: 158284

Committed r125550: <http://trac.webkit.org/changeset/125550>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.