Stack traces #26
Description
When reducing a syntax tree into an value, PlatformScript does not currently have the concept of tracking where exactly the node being evaluated was from in the event of an error, and furthermore, if that node was called from another part of the tree, it does not have the concept of maintaining the context of where the code being called was called from. This means it does not have the concept of an evaluation stack, and as we all know, debugging without stack trace is nearly impossible. It requires you mentally map any symbols you see in the error message back to where you think those same symbols appear in the source. This mental mapping process works for small scripts, but fails spectacularly for complex projects. In short, we need good stack traces.
PlatformScript needs to handle the following errors gracefully:
Evaluation Errors
Most errors fall into this category. They are what happens when you get a bad reference, or a function body raises an error. However, as a scripting language we need to also handle cases where errors cross the boundaries of a native (JavaScript) function. For example:
- How does a native function raise a platform script specific error (like no such reference).
- What happens when a native function raises an unhandled, non-platformscript error?
- How does a native function catch an error that is thrown from platformscript code that it is calling, evaling, or loading?
- What dose a native functions entry in a stack trace look like?
Syntax Errors
Syntax errors are slightly different in that they represent a failure to parse a piece of YAML. As such, they don't have as specific a line number, and they don't have an associated stack. However, when loading modules, there is the possibility that the syntax of the module is bad, and so we need to be able to preserve the stacking context of the code that loaded the module.