Sync Blob.close() behavior wrt updated spec.

Source/core/fileapi/Blob.h

Index: Source/core/fileapi/Blob.h
diff --git a/Source/core/fileapi/Blob.h b/Source/core/fileapi/Blob.h
index f63761cb63ff7352bba4f0816be78e9db5813a0e..1cd9d279d330005f0de8795f2fe6c5a9759884b8 100644
--- a/Source/core/fileapi/Blob.h
+++ b/Source/core/fileapi/Blob.h
@@ -41,6 +41,7 @@
 
 namespace WebCore {
 
+class ExceptionState;
 class ExecutionContext;
 
 class Blob : public ScriptWrappable, public URLRegistrable, public RefCounted<Blob> {
@@ -58,8 +59,23 @@ public:
     virtual ~Blob();
 
     virtual unsigned long long size() const { return m_blobDataHandle->size(); }
-    virtual PassRefPtr<Blob> slice(long long start = 0, long long end = std::numeric_limits<long long>::max(), const String& contentType = String()) const;
-    virtual void close(ExecutionContext*);
+    virtual PassRefPtr<Blob> slice(long long start, long long end, const String& contentType, ExceptionState&) const;
+
+    // To allow ExceptionState to be passed in last, manually enumerate the optional argument overloads.
+    PassRefPtr<Blob> slice(ExceptionState& exceptionState) const
+    {
+        return slice(0, std::numeric_limits<long long>::max(), String(), exceptionState);
+    }
+    PassRefPtr<Blob> slice(long long start, ExceptionState& exceptionState) const
+    {
+        return slice(start, std::numeric_limits<long long>::max(), String(), exceptionState);
+    }
+    PassRefPtr<Blob> slice(long long start, long long end, ExceptionState& exceptionState) const
+    {
+        return slice(start, end, String(), exceptionState);
+    }

[kinuko, 2014/03/03 05:18:46]

Oops... sad, is this the common way for adding exception state to a method with
optional args?

[sof, 2014/03/03 09:36:52]

It is definitely sad; I don't see a way to express this in IDL (i.e., annotating
the first two optional args with [Default=Undefined] would not be correct.)

nbarth: no way to avoid this situation, correct? i.e., a [RaisesException]
attribute on a method taking optionals will require more than one corresponding
method on the underlying object.

[Nils Barth (inactive), 2014/03/04 01:11:54]

No, I don't believe there's currently a cleaner way to do this.

2 thoughts:
1. We could pass ExceptionState in *first*, as that would allow C++ handling of
optional arguments with default values
2. We could implement default values for optional arguments (properly).
In fact, we probably should do both.

To clarify, the issue is that:
* Bindings code generates early calls for optional arguments w/o default values
* Default values can be specified in C++ (as previously here).
* However, this doesn't work if we have [RaisesException], since it is always
passed in, which breaks C++ method resolution.

If we specify default argument values in the IDL (which is clearer),
it would generate a single C++ call (not different ones per different
number of arguments), and we could remove all default values from C++:

[RaisesException]
Blob slice(
　　optional long long start = 0,
　　optional long long end = LLONG_MAX,
　　[TreatNullAs=NullString, TreatUndefinedAs=NullString]
　　optional DOMString contentType = null);

Refs:
// LLONG_MAX = 9223372036854775807
// 0x7FFFFFFFFFFFFFFF is a bit more legible
// needs to be included literally, unless we add some new keywords
// or other handling; might be useful if a common case.

http://heycam.github.io/webidl/#dfn-optional-argument-default-value

[sof, 2014/03/04 08:52:56]

Having default value support would be the way to go here. There's no real
reliance on having these arguments be defaulted on the C++ side.

The default for 'end' is what prevents just using [Default=Undefined] here,
which is something that doesn't appear common for other methods that uses
[RaisesException] and optionals.
Yes - WebIDL might want to predefine a set of these if type boundary
default values show up in several specs, I suppose.

+
+    virtual void close(ExecutionContext*, ExceptionState&);
 
     String type() const { return m_blobDataHandle->type(); }
     String uuid() const { return m_blobDataHandle->uuid(); }