efcore: Exception during IEnumerable param enumeration pretends to be a query problem

When EF receives an IEnumerable<T> query parameter, and an exception happens to be thrown during its deferred enumeration, EF logs an error as if something went wrong with the query. In actuality, the error had nothing to do with the query.

Let’s consider why one passes a deferred enumerable. At least not with the intent of making its enumeration a part of the query execution. 😃 Rather, say, because extra calls to ToList() reduce readability or are simply unnecessary.

For example:

var orderIds = inputModels.Select(model => model.OrderId);
// ToList() here would cause clutter - we are only enumerating once, after all

var orders = await dbContext.Orders
	.Where(order => orderIds.Contains(order.Id)
	.ToListAsync(cancellationToken);

Say that an exception is thrown during the enumeration of the IEnumerable<T>. A common use case for that is when we use DDD-style ValueObjects, such as an OrderId type. Perhaps OrderId is a string constrained to 50 alphanumeric characters. When the input does not satisfy the constraint, the OrderId constructor throws.

Suddenly, it matters way too much whether or not we add ToList() to the example’s first line:

• If we add ToList(), the exception occurs normally. Our exception handler might kick in, blame the exception on caller error, and return BadRequest, without polluting the logs with any errors.
• If we omit ToList(), the same things happen, but not before EF has logged an error!

Irrelevant error entries are the bane of any log’s usability, so the latter is quite undesirable. We could work around that by opting for the former, but how do we enforce that choice? Since the example was a natural way to write the code, spotting the “missing” ToList() would be an unreliable exercise.

Suggested solution

Exceptions caught during the enumeration of any IEnumerable query parameter should not cause EF to log. There is no difference of intent between the developer materializing the enumerable vs. letting EF enumerate it, so there should be no difference in the outcome either.

Implementation ideas

Some options:

• Materialize any non-materialized enumerable parameters upfront, before entering the relevant try/catch block. (For example, if is not IReadOnlyCollection<T>, then we must materialize.)
• Enumerate any enumerable parameters in their own try/catch block. Wrap potential exceptions in a custom exception type. At the existing outer catch that normally logs and rethrows, add a different catch for the new exception type. It simply unwraps the original exception and rethrows it.

Provider and version information

EF Core version: 7.0.0 Database provider: Microsoft.EntityFrameworkCore.SqlServer Target framework: .NET 7.0 Operating system: Windows 11 IDE: Visual Studio 2022 17.4.3