Improve handling of failed integer type conversions.

Source/modules/indexeddb/IDBCursor.cpp

Index: Source/modules/indexeddb/IDBCursor.cpp
diff --git a/Source/modules/indexeddb/IDBCursor.cpp b/Source/modules/indexeddb/IDBCursor.cpp
index 8ea735858c5ba2e5254bbb7ca3ec2074d93d6faa..ed68e84584ce7cb5e220a845a730adf99e6927d3 100644
--- a/Source/modules/indexeddb/IDBCursor.cpp
+++ b/Source/modules/indexeddb/IDBCursor.cpp
@@ -142,6 +142,10 @@ PassRefPtr<IDBRequest> IDBCursor::update(ScriptState* state, ScriptValue& value,
 void IDBCursor::advance(unsigned long count, ExceptionState& exceptionState)
 {
     IDB_TRACE("IDBCursor::advance");
+    if (!count) {

[jsbell, 2014/01/02 18:03:23]

Any particular reason for changing the order? lgtm anyway, since this case is
listed first in the spec (even though we couldn't get consensus on a strict
ordering in the spec).

[sof, 2014/01/02 19:30:31]

The spec was the motivation for moving it up, but also that it makes logical
sense to have it first -- to my mind, the >0 constraint being an extension of
[EnforceRange] validation of the argument. Hence having other observable
exceptions between these two parts would be unnatural.

But that's all API implementation machinery details -- if it is preferable to
keep it the way it was, happy to revert the placement.

+        exceptionState.throwTypeError("A count argument with value 0 (zero) was supplied, must be greater than 0.");
+        return;
+    }
     if (!m_gotValue) {
         exceptionState.throwDOMException(InvalidStateError, IDBDatabase::noValueErrorMessage);
         return;
@@ -160,11 +164,6 @@ void IDBCursor::advance(unsigned long count, ExceptionState& exceptionState)
         return;
     }
 
-    if (!count) {
-        exceptionState.throwUninformativeAndGenericTypeError();
-        return;
-    }
-
     m_request->setPendingCursor(this);
     m_gotValue = false;
     m_backend->advance(count, WebIDBCallbacksImpl::create(m_request).leakPtr());