Runtime error and type checking is incomplete

[TheBizzle]

The NetLogo compiler does a lot of typechecking for us, but, as soon as value is stored into a variable or procedure argument, we lose the type information. As a result, all of the compiler's typechecking must be duplicated at runtime, as well. Unfortunately, currently, many primitives don't do a good job of that, as demonstrated, for example, in NetLogo/Galapagos#363, but there are countless other examples.

We should implement this at some point. But, of course, adding all of these runtime checks will definitely induce a performance decrease to the simulation engine. But that's cost of "correctness", I suppose....

(Some work is already in progress for this on the wip-middle-layer branch.)

[LaCuneta]

An update on this issue for March 2021 and beyond. The type/runtime checking middle layer has been added, you can see the entry point for the work so far in the Checker class. Most checks for primitives for agentsets, lists, math ops, and more are already added. The compiler will automatically generate argument type checks for primitives as needed, and skip type checks when the types are known. Example: n-of (count turtles - 10) turtles will not generate any runtime type checks (n-of will check that the integer argument is valid for the number of turtles in the agentset).

Additionally, a RuntimeException has been added, that's meant to be the "expected engine runtime error" class, and it's been dropped into all appropriate places in the engine. All remaining existing errors that need to be moved out of the runtime and into the middle layer can be found by searching for exceptions.runtime() or exceptions.extension().

Also left to do are the the remaining skipped language tests in the TortoiseFinder. Many of those depend on procedure context also tracking the current agent type: observer, turtle, patch, or link, which would be a logical next thing to add.

And then still left to do are any engine errors that NetLogo desktop generates for which there are no language tests or docking tests. Finding these will be a bit painful, and the best way I can think of is to move the prims in SimplePrims.scala and Prims.scala one at a time to the appropriate "checked" section, looking at their NetLogo desktop/headless implementations to see if they raise errors as you go (and maybe adding language tests for those errors?).

[SethTisue]

Wow, awesome. 👏

[drocks13]

I have encountered the same error that was found in here https://github.com/NetLogo/Galapagos/issues/363 in a model we are using.

Both nlogo and html files attached in the zip so you can recreate it. Pretty easy to do. Click setup, then click go and a second or two into the simulation you get this error message:

"A type error has occurred in the simulation engine. More information about these sorts of errors can be found here.

Advanced users might find the generated error helpful, which is as follows:

agent.getCoords is not a function"

Here are the files runtime error.zip

By chance, is there any sort of quick work around to fix this issue? This is for a teaching tutorial so we can change things up, though we would like to use it for teaching in the new year.

[LaCuneta]

@drocks13 The issue there is with this code:

    let p patches with [not any? foragers-here and resources >= consumption-rate]
    if p != nobody [ move-to one-of p ]

The with reporter doesn't report nobody when there are no matches, it reports an empty agentset. So I think you want if any? p [ ... ]

If you do hit another case like this the easiest way to check what the real runtime error is is to load up the model in the desktop NetLogo application and run it there (the real error was "MOVE-TO expected input to be an agent but got NOBODY instead."). I know it's not ideal, but if the error is easy to reproduce, as with this one, then it's at least a fairly quick process.

[drocks13]

@LaCuneta thank you. That is good to know about checking in the desktop and will be sure to do that in the future.