Remove FileError interface

third_party/WebKit/Source/modules/filesystem/ErrorCallback.h

 /*
  * Copyright (C) 2010 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 13 matching lines @@
  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
  * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
  * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
 #ifndef ErrorCallback_h
 #define ErrorCallback_h
 
+#include "core/fileapi/FileError.h"
 #include "platform/heap/Handle.h"
 
 namespace blink {
 
-class FileError;
-
 class ErrorCallback : public GarbageCollectedFinalized<ErrorCallback> {
 public:
     virtual ~ErrorCallback() { }
     DEFINE_INLINE_VIRTUAL_TRACE() { }
-    virtual void handleEvent(FileError*) = 0;
+    virtual void handleEvent(DOMException*) = 0;
+    virtual void handleEvent(FileError::ErrorCode error) { handleEvent(FileError::createDOMException(error)); }

[foolip, 2016/06/23 12:04:48]

I don't think I quite understand the new role of the ErrorCallback interface.
It's a thing that's implemented by V8ErrorCallback so that our C++ can invoke
the callback in C++, but the new signature with the enum is for internal use and
in many cases handleEvent(DOMException*) is NOTREACHED(). Should these two
things be one thing (maybe I missed a necessary connection) or would it be
possible to have one thing that's purely for bindings and another for internal
use? It seems like this might get in the way in any refactoring of how callbacks
work, and I have thought about trying to make it such that WebIDL callback
interfaces and callback functions look the same to C++, as part of getting rid
of our bogus callback interfaces that are actually callback functions in the
specs.

[jsbell, 2016/06/23 19:44:29]

It is weird - I'll see if I can split it up.

It shows up where a sync API is implemented by calling the async API with e.g.
LocalErrorCallback which stashes the error code and then the sync API throws.

One approach would be to add ErrorCallbackBase which has only
handleEvent(FileError::ErrorCode). Internal uses subclass from this. Then we
could have a ScriptErrorCallback subclass that holds a the bindings-facing
ErrorCallback. Internal APIs would be changed to take ErrorCallbackBase,
script-facing APIs would wrap an ErrorCallback in ScriptErrorCallback.

 };
 
 } // namespace blink
 
 #endif // ErrorCallback_h