Error propagation issues obfuscating root causes

[Alfus]

We are seeing errors like:

found no matching overload for _?_:_ applied to '(<class 'celpy.evaluation.CELEvalError'>, <class 'celpy.celtypes.StringType'>, <class 'celpy.celtypes.StringType'>)'", <class 'TypeError'>, ("Unexpected <class 'celpy.evaluation.CELEvalError'> ? <class 'celpy.celtypes.StringType'> : <class 'celpy.celtypes.StringType'>

Which is obfuscating the underlying error that occured in the argument to conditional.

This appears to be happening because the arguments to both registered and builtin functions are not being checked before passed in as celtypes.Value. Ideally 'strict' functions would have all the arguments sanctity checked, and any errors in the arguments would be propagated instead of invoking the function, while the logical operators, && and ||, and built in '@not_strictly_false` should be tolerant of some errors in the arguments.

[kapilt]

pull requests welcome

[slott56]

It's not perfectly clear (to me) what the benchmark Go implementation does in this case.

I'm unclear on where the Go implementation does type-checking.