Add more data to conversion failure messages in gin

This CL also makes it more clear in gin when type
coercion fails what argument (0-indexed) failed
to convert and what js type was seen in the process.

I started down the path of logging the c++ destination
type as well, but found I couldn't with our current
RTTI-less build.

This was already reviewed in:
https://codereview.chromium.org/798163002/
before I realized that gin was maintained in chromium.

TBR=abarth@chromium.org
BUG=

Review URL: https://codereview.chromium.org/805993002

Cr-Commit-Position: refs/heads/master@{#308435}

2 files changed, 21 insertions, 3 deletions

diff --git a/gin/arguments.cc b/gin/arguments.cc
index 6703fc2..30ff784 100644
--- a/gin/arguments.cc
+++ b/gin/arguments.cc
@@ -32,12 +32,26 @@ v8::Handle<v8::Value> Arguments::PeekNext() const {
   return (*info_)[next_];
 }
 
+std::string V8TypeAsString(v8::Handle<v8::Value> value) {
+  if (value.IsEmpty())
+    return "<empty handle>";
+  if (value->IsUndefined())
+    return "undefined";
+  if (value->IsNull())
+    return "null";
+  std::string result;
+  if (!ConvertFromV8(NULL, value, &result))
+    return std::string();
+  return result;
+}
+
 void Arguments::ThrowError() const {
   if (insufficient_arguments_)
     return ThrowTypeError("Insufficient number of arguments.");
 
-  ThrowTypeError(base::StringPrintf(
-      "Error processing argument %d.", next_ - 1));
+  return ThrowTypeError(base::StringPrintf(
+      "Error processing argument at index %d, conversion failure from %s",
+      next_ - 1, V8TypeAsString((*info_)[next_ - 1]).c_str()));
 }
 
 void Arguments::ThrowTypeError(const std::string& message) const {
diff --git a/gin/function_template.h b/gin/function_template.h
index 2b66b66..dff1bb2 100644
--- a/gin/function_template.h
+++ b/gin/function_template.h
@@ -131,8 +131,12 @@ struct ArgumentHolder {
 
   ArgumentHolder(Arguments* args, int create_flags)
       : ok(GetNextArgument(args, create_flags, index == 0, &value)) {
-    if (!ok)
+    if (!ok) {
+      // Ideally we would include the expected c++ type in the error
+      // message which we can access via typeid(ArgType).name()
+      // however we compile with no-rtti, which disables typeid.
       args->ThrowError();
+    }
   }
 };