Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

please add ability to get a stacktrace from errors and exceptions #112

Closed
karoberts opened this issue Nov 12, 2014 · 3 comments · Fixed by #821
Closed

please add ability to get a stacktrace from errors and exceptions #112

karoberts opened this issue Nov 12, 2014 · 3 comments · Fixed by #821

Comments

@karoberts
Copy link

I'm building an engine that uses Jint to execute a javascript file with a bunch of functions.

The problem is that if there is

  • a syntax error
  • a runtime error
  • a throw new Error()

all you get out of Jint is a JavaScriptException with no context as to where the error occurred.

Right now I'm relegated to adding log statements just to find the problem in the script.

It would be extremely helpful if any throwing of Error() would come with the stack property filled in with the stacktrace of the js functions.

@christianrondeau
Copy link
Contributor

I had the same problem, where some long scripts would be extremely hard to debug. What we did is wrap Engine.Execute in our own try block, and re-throw with the Engine.GetLastSyntaxNode().Location.Start values. Example:

var engine = new Engine();
try
{
  engine.Execute("some code that throws...");
}
catch(JavaScriptException exc)
{
  var location = engine.GetLastSyntaxNode().Location.Start;
  throw new ApplicationException(
    String.Format("{0} (Line {1}, Column {2})",
      exc.Error,
      location.Line,
      location.Column
      ), exc);
}

Note that it would be much better if the location object was always part of the JavaScriptException object.

@karoberts
Copy link
Author

Thanks, that is very helpful.

I still think it would be very valuable to have a stacktrace available. The reason is that (in my case) the script is dynamically assembled, so getting from a line number to the actual line in the dynamic script takes a little extra work.

@77it
Copy link

77it commented Jan 5, 2020

For some parsing errors I encountered also the Esprima.ParserException exception.
And I found useful to add also the text of the line causing the error (as printed in ClearScript exception)

public void Run(string script)
{
    JintEngine.Execute(script);

    catch (Esprima.ParserException ex)
    {
        throw new ApplicationException($"{ex.Error} (Line {ex.LineNumber}, Column {ex.Column}), -> {ReadLine(script, ex.LineNumber)})", ex);
    }
    catch (Jint.Runtime.JavaScriptException ex) 
    {
        throw new ApplicationException($"{ex.Error} (Line {ex.LineNumber}, Column {ex.Column}), -> {ReadLine(script, ex.LineNumber)})", ex);
    }
}

private static string ReadLine(string text, int lineNumber)
{
    using var reader = new System.IO.StringReader(text);

    string line;
    int currentLineNumber = 0;

    do
    {
        currentLineNumber += 1;
        line = reader.ReadLine();
    }
    while (line != null && currentLineNumber < lineNumber);

    return (currentLineNumber == lineNumber) ? line : string.Empty;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants