Getting V8 compilation error details, and uncaught exceptions stack traces

Jul 1, 2013 at 10:07 AM
There seems to be some missing informations about javascript errors. (Or maybe there is a way to get the error details but I can't figure it out). The V8Exception, and subsequent ScriptEngineException, does not carry some necessary details like source code line, or exact error position. These details may be available via class v8::Message accessible from TryCatch::Message() in function :
V8ContextImpl::Verify(const TryCatch& tryCatch)
{
[ ...]
   if (! tryCatch.Message().IsEmtpy())
   {
           message->GetScriptResourceName();
           message->GetLineNumber();
           message->GetSourceLine();
           message->GetStartColumn();
           message->GetEndColumn();
           // etc..
   }
[...]
 }
  • The target scenario where these informations are invaluable in contrast to what the ScriptEngineException actually contains is a compilation error (can't get source line in error)
run.Execute("dummyDocument.js", @"
for (var i = 0; i < 30000; i++ )
{
    int c;
    c++;
}
  • Another scenario where some informations are missing : an Uncaught exception (we can't get stack trace)
run.Execute("dummyDocument.js", @"
function foo()
{
    throw 1;
}
function bar()
{
    foo();
}
function toto()
{
    bar();
}
toto();
");
The V8 source code documents that the SetCaptureStackTraceForUncaughtExceptions must be enabled for that scenario. It would be great if we could enable these kind of options within clearscript.
Coordinator
Jul 1, 2013 at 2:29 PM
Hello julien_b! We're investigating these issues. Thanks for reporting them!
Coordinator
Jul 1, 2013 at 3:47 PM
We have reproduced two issues:
  1. V8ScriptEngine currently collects error details only when the thrown object is an Error instance. This covers system-generated errors and thrown Error instances but not arbitrary thrown values.
  2. V8ScriptEngine currently does not collect error details for syntax errors.
We will fix these issues ASAP. In the meantime, you might be able to work around the first issue by throwing an Error instance; e.g., throw new Error(1) rather than throw 1. Unfortunately there is no workaround for syntax errors.
Coordinator
Jul 3, 2013 at 3:19 AM
We've posted an update that fixes these issues. Thanks again for your input!