Example: Consider one file calling another file like so:

// THIS is "prog1.ks", which runs prog2.
run prog2.ks.

// This is "prog2.ks" where the error really is.

// This scientific notation is too big to fit in a double, and kOS does produce an error
// for that.
// BUT because the syntax of digits, 'e', more digits, is is perfectly valid in the grammar,
// this doesn't get caught in parsing, instead Compiler.cs complains when analising
// the parsed tree:
set x to 99e999999999999.

Then you run these by doing this:

run prog1.ks.

When you do this (errors that Compiler.cs throws instead of the parser throwing them), sometimes the error message will claim the calling program that called the inner program is where the error is, and that's not true.

In the above example, the error message will claim it's prog1.ks that is in error, not prog2.ks.

The reason is because the exception catcher that logs the error assumes the error is the fauilt of the opcode instruction that was being executed when the error happened, but that opcode is the place where the caller loaded the program that wouldn't compile.