[BUG] Azure.Data.Tables TableClient.CreateIfNotExistsAsync throws with 409 conflict instead of returning null

Describe the bug The documentation says that TableClient.CreateIfNotExistsAsync will return null if the table already exists. It actually doesn’t. It throws with Status of Conflict

Expected behavior CreateIfNotExistsAsync implies it will not throw if it does exist. Otherwise what value is this method over Create ?

Actual behavior (include Exception or Stack Trace)

It throws RequestFailedException with Status of 409

ps: Q: what is the difference between this library and Microsoft.Azure.Cosmos.Table which is not deprecated, but not updated since 2020. Q: Why not name this library Azure.Storage.Tables to match Azure.Storage.Blobs

To Reproduce Steps to reproduce the behavior (include a code snippet, screenshot, or any additional information that might help us reproduce the issue)

1. Run the below code on a table of your choice. 2.Set a breakpoint in the catch clause on the second run.

               try
                {
                    await this.tableClient.CreateIfNotExistsAsync(cancellationToken);
                }
                catch (RequestFailedException exception) when (exception.Status == (int)HttpStatusCode.Conflict)
                {
                    // Already exists.
                }

Environment:

• Name and version of the Library package used: [e.g. Azure.Data.Table12.2.1] Azure.Data.Tables 12.2.1
• Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): [e.g. Azure AppService or Windows 10 .NET Framework 4.8]

This is just debugging in the IDE from a console app. .Net 5.0.

• IDE and version : [e.g. Visual Studio 16.3] Visual studio 16.11.5.

[nschuessler]

Oy vey, you are right. I was manually testing and turned on first chance exceptions looking for calls to GetEntityAsync<T> that didn’t have catches for Status=404 and was thinking I also needed handling on the CreateTableIfNotExistsAsync when this triggered.

Looks like this is by design. I’ll remove the catch for that api.

[christothes]

Does this only throw in the debugger when it is configured to break on all exceptions, including first chance? There is a first chance exception that occurs there, but it is caught and handled.