[FJ7] Runtime errors

Test case contains contains invalid function defs:

85();
"not a function"();

According to the instruction:

The tester will assert ... the exit code is 70.

70 is for runtime error
65 for parsing error

Such cases can be (should be?) detected during parsing stage when creating AST.

Maybe better to expect parsing error for the case (65) or even keep both as valid error code?

Hi @secrary, thanks for sharing your perspective!

I agree that a case could be made for making this as a ParseError. However, the author of the Lox language decided to make it a RuntimeError:

https://craftinginterpreters.com/functions.html#call-type-errors

So our tester follows this decision to stay consistent with the book.

1 Like

After visiting again, it make sense for cases where we have chained calls and first one returns invalid type for the function:

returnsFn(arg1)(arg2) // <= all good
returnsNum(arg1)(arg2) // <= here maybe better to delegate the desicion to runtime or later stages at parsing

but cases where we can see that it’s Number or Bool better to be ParseErr

33();

Even though, best case I think would be to detect whatever is possible at parsing stage and rest at runtime, better to stick whatever is preferred way in the book. It’s an exercise.

Thanks Andy!

1 Like

Closing this thread due to inactivity. If you still need assistance, feel free to reopen or start a new discussion!

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.