[WebIDL] Make ExceptionCode the first parameter instead of the last when using [RaisesException]

[Chris Dumez]

Make ExceptionCode the first parameter instead of the last when using [RaisesException].

Whenever a method is marked as [RaisesException], we currently pass an extra ExceptionCode& as last parameter to the implementation method. The issue with it being last is when we have optional parameters. This forces people to add overloads instead of using inline default parameter values in the C++.

E.g.
IDL:
[RaisesException] ScriptProcessorNode createScriptProcessor(unsigned long bufferSize, optional unsigned long numberOfInputChannels, optional unsigned long numberOfOutputChannels);
    
C++:
RefPtr<ScriptProcessorNode> createScriptProcessor(size_t bufferSize, ExceptionCode&);
RefPtr<ScriptProcessorNode> createScriptProcessor(size_t bufferSize, size_t numberOfInputChannels, ExceptionCode&);
RefPtr<ScriptProcessorNode> createScriptProcessor(size_t bufferSize, size_t numberOfInputChannels, size_t numberOfOutputChannels, ExceptionCode&);

Would become:
RefPtr<ScriptProcessorNode> createScriptProcessor(ExceptionCode&, size_t bufferSize, size_t numberOfInputChannels = 2, size_t numberOfOutputChannels = 2);

[Chris Dumez]

Any objections?

[Darin Adler]

A better approach would be to come up with a way for the return value to be a union of the other return value type and an ExceptionCode. We could make a class template that is a bit like Optional<> that allows a value either of type T or an ExceptionCode. This would be more elegant than an out argument, regardless of argument ordering.

[Chris Dumez]

(In reply to comment #2)
> A better approach would be to come up with a way for the return value to be
> a union of the other return value type and an ExceptionCode. We could make a
> class template that is a bit like Optional<> that allows a value either of
> type T or an ExceptionCode. This would be more elegant than an out argument,
> regardless of argument ordering.

Ok, that sound worth exploring indeed.

[youenn fablet]

Sounds good to me.
I am not sure whether we would like to remove RaisesException keyword, but it seems like this may help doing  meta programming.

[Darin Adler]

(In reply to comment #4)
> I am not sure whether we would like to remove RaisesException keyword, but
> it seems like this may help doing  meta programming.

I would very much like to remove those keywords about raising exceptions if we can get the code generated in a way that’s still just as efficient. And I agree there’s a good chance we can with overloading and various meta-programming techniques.

[Darin Adler]

I did the ExceptionOr thing, so we won’t have to do this.