Currently, when partial evaluation encounters an expression that throws an exception when executed in memory, the exception is propagated to the caller, and query parsing stops.
As an example, consider the following query:
Since c.ID cannot be evaluated, re-linq evaluates nullValue != null and nullValue.Length separately; the latter causes a NullReferenceException to be thrown.
It is desirable for partial evaluation to cope with such exceptions and optionally let the back-end decide how to deal with the exception. Therefore, implement the following fix:
when partial evaluation encounters an exception, catch the exception and capture it within a PartialEvaluationExceptionExpression;
then continue partial evaluation on the child expressions of the throwing expression.
The PartialEvaluationExceptionExpression reduces itself (when calling ExtensionExpression.Reduce) to the evaluated child expression. This enables back-ends not explicitly dealing with PartialEvaluationExceptionExpressions to just ignore the exception. Back-ends that want to deal with the exception can implement IPartialEvaluationExceptionExpressionVisitor.
As a result, back-ends unaware of the PartialEvaluationExceptionExpression should behave as if they received the following evaluated query from the front-end (as long as they support ExtensionExpressions):