Efcore: Document exceptions that should not be caught as part of normal flow control (i.e. most of them)

[linhub15]

Asynchronously returns the only element of a sequence, and throws an InvalidOperationException exception if there is not exactly one element in the sequence.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d3b7deb0-a592-b6dc-1564-fba73a4dcb4c
• Version Independent ID: 1836b7d9-419e-d8a4-51ff-09f504a56462
• Content: EntityFrameworkQueryableExtensions.SingleAsync Method (Microsoft.EntityFrameworkCore)
• Content Source: dotnet/xml/Microsoft.EntityFrameworkCore/EntityFrameworkQueryableExtensions.xml
• Product: entity-framework-core
• GitHub Login: @dotnet-bot
• Microsoft Alias: divega

[ajcvickers]

@linhub15 We can document the type of exception thrown, but I'm curious as to why it matters? It is not intended that this exception be expected and caught as a normal part of an application running. It is intended to indicate that there isn't a single element and therefore calling this method was an invalid operation.

[linhub15]

I wasn't sure if other Exceptions would bubble up from SingleAsync() so
Rather than:

catch (Exception e) { ... } 

I wanted to use:

catch (InvalidOperationException e) { ... } 

So I could throw my custom Exception EntityNotFoundException

---

I think I used this method incorrectly...

In hind sight I should have used SingleDefaultOrAsync to check for default, then throw my Exception.

[ajcvickers]

Team notes: after discussing this we think it would be more helpful to:

• Document exceptions that are intended to be caught for some scenarios. (Basically, just DbUpdateConcurrencyException.)
• Document that other exceptions (like this one) are intended to indicate that the application is doing something wrong and therefore should not be caught other than as part of reporting/logging the application fault.

[ajcvickers]

Duplicate of #17692