Jurassic not returning an error's file and line number on function execution

Jul 25, 2013 at 7:26 AM
Perhaps it's a limitation in the engine, perhaps not but when I execute code it seems to lose the filename of the code that was loaded in:
engine.ExecuteFile("file.js");

//...

try {
    engine.Execute("my_func();");
}
catch(JavaScriptException e) {
    Console.WriteLine(e);
}
It does give me the error but give no line number or file. The function my_func() would have been defined in that file, and have something other than a syntax error in it. Syntax errors in files/script sources are reported fine BTW.

For sake of completion, such a function would look like this:
function my_func() {
    return 5 + prop;
}
A lot of engines will not only say prop is not defined, but say that it also happened on line 'x', and in file 'blah.js'.
Jul 27, 2013 at 7:42 AM
Edited Jul 27, 2013 at 7:58 AM
I think you can do like this, if I understood your problem.
 public class JurassicConsole
    {
        Jurassic.ScriptEngine engine;

        public JurassicConsole(bool EnableDebugging)
        {
            this.engine = new Jurassic.ScriptEngine();
            this.engine.EnableDebugging = EnableDebugging;
        }

        public void ExecuteFile(string file)
        {
            try
            {
                this.engine.ExecuteFile(file);
            }
            catch (Jurassic.JavaScriptException ex)
            {
                System.Diagnostics.StackFrame stackFrame = new System.Diagnostics.StackFrame(1, true);                      
                string message = "FileName: " +stackFrame.GetFileName() + "Line No: " + stackFrame.GetFileLineNumber();
                throw new Exception(message);
            }
        }
    }
Jul 28, 2013 at 1:18 AM
Edited Jul 28, 2013 at 1:18 AM
Nope, that doesn't work. I'm looking for the JS filename and line number. Hmm, another better example:
try {
    engine.Execute("my_func();");
}
catch(JavaScriptException ex) {
    Console.WriteLine(string.Format("Script error in \'{0}\', line: {1}\n{2}", ex.SourcePath, ex.LineNumber, ex.Message));
}
You'd think that would work all-around, but only for syntax errors; nothing more.
Coordinator
Jul 29, 2013 at 3:32 AM
There's a branch called "add-error-stack" which greatly improves javascript stack traces in Jurassic. Are you able to try the same test on that branch? If not, I'll check it out when I get a chance.
Coordinator
Jul 29, 2013 at 6:29 AM
The add-error-stack branch does fix the issue. I've merged in that branch so you should get the fix if you do a pull.
Aug 1, 2013 at 9:27 PM
Thank you very much!
Aug 3, 2013 at 1:43 AM
Hmm not quite all cases, these types of error go unnoticed:
Script error in '', line: 0
TypeError: undefined cannot be converted to an object
It might seem obvious, but I am running fairly meaty JS files that call all kinds of globally bound CLR functions and one of them is taking an invalid parameter (easily fixable on the C# side), if only I knew where it was. The method I had been using to solve this is combing through both JS and C# source to see where the issue is, but that can take a lot of time. I know it's not the JS code, it's in the C# since the code would work in another environment had in this case worked up until today where a regression kicked in, but that doesn't matter in this case, an error report should give the correct location.

Most other cases it works very well and good at determining where runtime errors are that aren't associated with bound functions.
Coordinator
Aug 5, 2013 at 8:37 AM
Totally agreed. I've checked in a fix for this issue. Can you give it a whirl and let me know how you get on?
Aug 5, 2013 at 10:17 PM
It works well enough but for an object that doesn't have a property I'd rather see a message:
TypeError: obj[something] has no properties.
rather than a type conversion error for undefined. ;)
Coordinator
Aug 6, 2013 at 12:24 AM
The "convert to object" behaviour is used in a bunch of places, but yes, the error message could be better :-)