Azure-sdk-for-net: [TABLES] GetEntity/Async should not throw exception on 404

[kieronlanning]

Azure.Data.Tables

Is there an option to prevent GetEntity/ GetEntityAsync from throwing an exception in the case of an entity not existing.

[jsquire]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[christothes]

@kieronlanning If such an option existed, could you describe how you'd see it working?

[kieronlanning]

@christothes I think the best solution would be to add it to the TableOptions class in the constructor for the TableServiceClient (sorry if these aren't quite correct, I'm remembering the names from memory!).

That way the developer in question can choose the default on creation. But I do think you'd want to set it per-client, rather than per-call.

As for the GetEntity method itself, I'd like to see that return a null value with the response. So you can check the response for a 404 and return null accordingly. More choice. Right now I'm catching the exception and using the when clause to return null on a 404.

[christothes]

@kieronlanning Thanks. Could you also describe what you'd typically do after this call? For example, is the intent to just check for existence of an entity or would you actually want something like CreateIfNotExists or DeleteIfExists?

[kieronlanning]

@christothes For GetEntity it's always to check if it exists, but not always will we want to create or delete based on the result.

Sometimes it can form part of a HEAD request from the client, so it's a quick and easy way of returning some metadata to the client about the state of a resource.

Other times I might want to create it, but that's a rare case for me.

---

My context is this:

I use Table Storage for an Event Store Framework - the events are represented in table storage as individual entities. This gives my clients transactions (multiple events, plus additional entities for management of the store) and idempotency, as well as etag based updating where appropriate. Couple that with blob storage for snapshotting and large events and Azure Storage is a really solid platform.

That's why I'm so keen to get this Table API right. I'm close at the moment too - about 50 integration tests failing.

[christothes]

@kieronlanning Generally, the guideline we follow in the newer "track 2" SDKs is to throw in scenarios like this. I realize this is a change in behavior from the older client, but it would be consistent with the behavior found in other track 2 clients.

Is there any blocking reason your code couldn't handle the exception in the scenario where GetEntity throws due to a 404?

[kieronlanning]

@christothes That's a genuine surprise as the guidelines have always stated that throwing exceptions can be orders of magnitude slower (see https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions-and-performance)

But, as that guidance suggests error code shouldn't be used either - which is problematic, because HTTP responses rely on error codes.

However, the idea behind the Try-Parse Pattern could work in this instance?

A TryGetEntity and TryGetEntityAsync that doesn't throw by default. Would that be acceptable?

[christothes]

In the general case, you are correct that exceptions should be avoided if possible for performance sensitive code paths. However, in this scenario, we've already incurred the performance hit of a network call, which is much more expensive than throwing an exception.

For reference, here is the guideline relating to unsuccessful service method calls - https://azure.github.io/azure-sdk/dotnet_introduction.html#dotnet-errors

[christothes]

@kieronlanning Thank you for the feedback on this issue. I'm going to close this as by design, as it conforms to the guidelines. Please re-open with any additional information if the current behavior would be blocking for you.