Add an Error class for ServiceWorkers

public/platform/WebServiceWorkerError.h

 /*
  * Copyright (C) 2013 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 10 matching lines @@
  * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
  * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  * 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 WebCallbacks_h
-#define WebCallbacks_h
+#ifndef WebServiceWorkerError_h
+#define WebServiceWorkerError_h
+
+#include "WebString.h"
 
 namespace WebKit {
 
-template<typename S, typename T>
-class WebCallbacks {
+class WebServiceWorkerError {
 public:
-    virtual ~WebCallbacks() { };
-    virtual void onSuccess(S*) { };
-    virtual void onError(T*) { };
+    virtual ~WebServiceWorkerError() { };
+    virtual const WebString& message() = 0;

[michaeln, 2013/10/15 01:28:48]

It might be better/safer/easier-to-code-to to return the WebString on the stack
instead of a pointer/ref to it.

+    virtual const WebString& name() = 0;

[michaeln, 2013/10/15 01:28:48]

We'll have to be careful about the 'name' values.

I think error names are something that rightly should be defined in blink. Those
are very close to content facing api, a part of that api really. Given how this
is composed, chromium code has to pass in the right name. That seems sketchy and
a temptation to share string definitions would be icky from a linkage point of
view.

Should we consider a level of indirection here where we use numeric error codes
defined in WebKitAPI and have the blink/webkit layer fill in the appropiate
string value for the any underlying DOMError that gets cons'd up? In other cases
in the webkia api, in see enums used to define related set of errors.

[kinuko, 2013/10/15 01:43:09]

Does this need to be a pure abstract virtual class?

[kinuko, 2013/10/15 02:07:17]

+1 to have numeric error codes (unless we have other better scheme which is
known to be non-error-prone and simple).  It's a bit old-fashioned, but
imagining how we'll be handling errors in blink (other than just passing it to
scripts via reject()) usually numeric error code works just fine, and especially
while we're in early development phase I'd like to have simple and solid error
reporting mechanism.

 };
 
 } // namespace WebKit
 
 #endif