Not a big fan of these implicit trickeries, but if you do go for this you definitely have to handle status codes as well.
Unhandled exceptions in controllers will get converted to a 500 status code which indicate a server error - something that should hopefully happen rarely. If you want to return an error to the client you do this via 4xx status codes.
Using an async using block instead of the manual try/catch and then simply committing if the status code is 2xx is much less code and handles exceptions and status codes in one go.
Not a big fan of these implicit trickeries, but if you do go for this you definitely have to handle status codes as well.
Unhandled exceptions in controllers will get converted to a 500 status code which indicate a server error - something that should hopefully happen rarely. If you want to return an error to the client you do this via 4xx status codes.
Using an async using block instead of the manual try/catch and then simply committing if the status code is 2xx is much less code and handles exceptions and status codes in one go.
Well, this middleware is about handling transaction and you can implement exception handling middleware to catch errors and translate to proper status code like this one What every ASP.NET Core Web API project needs - Part 3 - Exception handling middleware, it's about separating concerns.