source location is not available in some important run-time errors

[GrahamAsher]

I have been trying to add informative error messages to my code that uses TeaScript and have run into a problem that makes it much harder for users to debug their code. The problem occurs both when interpreting the code and when running compiled code. The code is syntactically correct and compilation is successful.

In this relatively short piece of code there is an error:

            {
            def power := input("power")
            if (power is String)
                {
                if (power == "line" or power == "minor_line")
                    {
                    copy("_","voltage")
                    copy("_","ref")
                    if (input("layer") > 0)
                        { set_level(input("layer") + 1) }
                    }
                def height := input("height")
                if (height is String)
                    { set("_t",height) }
                if (power == "line") { commit("power/major","pwl",LINE) }
                else if (power == "tower") { commit("power/major","pwt",POINT) }
                else if (power == "minor_line") { commit("power/minor","mpl",LINE) }
                else if (power == "pole") { commit("power/minor","pwp",LINE) }
                else if (power == "substation") { commit("power/minor","pss",if (is_osm_node) { POINT } else { POLYGON }) }
                }
            }

It's not at all obvious. The error is that is_osm_node is a function, not a boolean variable, so a runtime exception is thrown at line 960 of ValueObject.cpp:

            []( auto ) -> bool { throw exception::bad_value_cast("ValueObject not convertible to bool!"); },

Imagine going through hundreds of lines of code trying to find out why it happened. Not a pleasant prospect.

The solution is for the interpreter to trap the exception and add location information (line and column number) to it, then re-throw. Execution of a compiled program cannot and need not do that; users can run their programs in the interpreter to find an error. Indeed, I tried doing that. In my error handler for compiled programs I retried running the program's source code in the interpreter to see if it would yield more useful information, but to no avail. Hence this report.

[Florian-Thake]

Thank you for reporting this issue!

Yes, unfortunately not all places, where exceptions are thrown, have a proper set SourceLocation already. It is a gap in the feature set.

My goal is to improve the debugging experience in an ongoing iterative way step by step.

I will look into this more thoroughly at a good opportunity.

In the meanwhile, are you using the TeaScript Host Application for testing and debugging purposes? (It is not officially available for macOS, but you can use it on Windows and Ubuntu/Linux). It is linked here in GitHub under 'Releases'.

You could execute the script and probably inspect its state when it is halted because of an error.
For example TeaScript.exe --debug -i <scriptfile> (there are other possibilities, also from inside the REPL).
Once you have the script in halted condition (after the exception was thrown and caught by the TeaStackVM), you may inspect the program state by :pc, :callstack or :dbinfo.

If you cannot use the TeaScript HostApplication you could try to build your own debugging setup with the help of TeaScript C++ Library only.
For this you must use the low level interface, in this case the teascript::StackVM::Machine + teascript::StackVM::Program.
Derive from the Engine, then you have access to the mBuildTools member which holds the machine.
Use 'compile' mode (eMode::Compile) but with optimize set to eOptimize::Debug.

Try to use GetCallStack(), GetCurrentProgram(), GetCurrentInstructionIndex() and GetSourceLocationFor()/GetBestMatchingSourceLocationFor() to find out what was going on and where it stopped.

[GrahamAsher]

@Florian-Thake Thanks for the advice. I haven't yet tried the TeaScript Host Application.

[Florian-Thake]

There are several points to improve debugging and user (developer) experience over the time:

1. Add SourceLocation to more and more places where they are missing now. This is an ongoing change. But especially at this particular place it will most likely be practical impossible. The GetAsBool() and similar functions of the ValueObject can be called from any place, not only from from code evaluation. To add an optional SourceLocation parameter to all of these functions just looks odd. So, the option would be: Covering more and more places in the AST eval code and catch the exception, insert the SourceLocation and re-throw. This will be also done in an ongoing improvement.
2. Replace more and more exceptions with return an Error instead. Then the error can be handled in the TeaScript code and the script can continue (or fail). Good places for this are out-of-range errors, maybe overflow or div-by-zero for example. But again for this concrete place it would not be sufficient. if in if (is_osm_node) { POINT } else { POLYGON } the is_osm_node will be cast to an Error it will not help at all. Instead the error will be silent and the else part will be executed (Error always converts to false).

I have a new idea, which I want to write down here. I want to generally improve the debugging capabilities.
My idea is

• introducing a breakpoint statement. Reaching this in Debug mode will raise a real breakpoint in Visual Studio or gdb. In Release build nothing will happen.
• Introducing a new class Debugger derived from the Engine. This class will have an interface to help tracking down the root cause of an issue, e.g, run until specific (instruction) positions (maybe even source code lines) in the code, discover the corresponding surrounding source lines, iterate through callstack, local variables, etc.

Since this whole topic is fitting well for the next release(s), I am going to plan this further.