Error propagation issues obfuscating root causes

[Alfred Fuller]

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.

[Kapil Thangavelu]

pull requests welcome