We should remove custom bindings as CodeGenerator uses UNUSED_PARAM macro. This was introduced in r72838.
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?
(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.
Comment on attachment 158284 [details] Patch OK
(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 :(.
(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".
Comment on attachment 158284 [details] Patch Clearing flags on attachment: 158284 Committed r125550: <http://trac.webkit.org/changeset/125550>
All reviewed patches have been landed. Closing bug.