Timeline for Dealing with API errors
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 19, 2019 at 13:08 | history | edited | Ewan | CC BY-SA 4.0 | added 6 characters in body |
| Jun 19, 2019 at 13:02 | history | edited | Ewan | CC BY-SA 4.0 | added 1333 characters in body |
| Jun 19, 2019 at 12:51 | comment | added | Ewan | nonsense! check before and throw if fails is the best pattern. If you need to guarantee the check is still good, then : begin trans, check, command, commit | |
| Jun 19, 2019 at 12:26 | comment | added | David Arno | Indeed. What's needed is a "TryPlaceOrder" that uses transactions behind the scene and responds with a success or an error-with-details response. No exceptions should come anywhere near this unless the API call itself is invalid or the server fails for some reason (not having stock is not one such failure) | |
| Jun 19, 2019 at 12:25 | comment | added | Ewan | if indeed its a problem. obviously the call fails either way. and both ways allow you to see which item is out of stock after a failed call | |
| Jun 19, 2019 at 12:23 | comment | added | Ewan | This problem is solved with transactions | |
| Jun 19, 2019 at 11:10 | comment | added | David Arno | "...it can call to check the stock levels before placing the order...". And between the check stock level call and submit order, another order comes in and that second order fails. So the check stock level call was pointless. What you describe is exactly the way it should not be done. | |
| Jun 19, 2019 at 7:51 | history | answered | Ewan | CC BY-SA 4.0 |