Add an Error class for ServiceWorkers

public/platform/WebServiceWorkerError.h

Index: public/platform/WebServiceWorkerError.h
diff --git a/public/platform/WebCallbacks.h b/public/platform/WebServiceWorkerError.h
similarity index 86%
copy from public/platform/WebCallbacks.h
copy to public/platform/WebServiceWorkerError.h
index ba023d32cce145c7a5cf7f38e9693a86f6a8bff3..fafb3c0c572a86ab364151138e9bfe08dedd5e79 100644
--- a/public/platform/WebCallbacks.h
+++ b/public/platform/WebServiceWorkerError.h
@@ -28,17 +28,18 @@
  * 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