Is panic recovery required / can it be disabled?

[mdmcconnell]

I have an application that evaluates many nested expression. When I have a problem, I want to panic and step out of the call stack, but expr recovers and creates an error, unwinding the whole stack. It isn't that much of a problem, but does lead to confusing, verbose error messages. Here is a trivialised example: https://go.dev/play/p/FZfvR0qI6zQ
Is possible to let panic be panic within expr?

[antonmedv]

I see. But vm has to recover from panics. For example, this expression will panic foo.bar if foo in unknown.

[mdmcconnell]

Hmm, yes. I didn't know/consider that membership is handled by go runtime, and not explicitly tested in Fetch.

[antonmedv]

Also some other custom defined functions can panic as well.

[antonmedv]

You could also try to inline evals. Write a custom patcher which will create ast on compile time and inject into parent ast.

[mdmcconnell]

That's a really nice idea, thank you! I will have to try it. I have a lot of tokens that represent expressions to be evaluated. If I lever the expr runtime to perform that recursion "earlier", I ought to gain performance versus setting up compilers and VMs 20 levels deep.

Though I also will get a 20 level deep ast, that may have its own error-checking difficulties.