Exercise 1: Why a 500 Isn't Automatically a Genuine Server Failure — Possible Solution ==================================================================== WHAT THIS CHAPTER SAYS ------------------------------ Per this chapter's warn-box, "plenty of applications return 500 for things that are really the client's fault (a validation error that should have been a 400) or an ordinary business-logic outcome (like 'insufficient inventory') that shouldn't be an error status at all." WHY THIS HAPPENS ------------------------------ Applications choose their own status codes, and that choice isn't always made carefully - a developer catching an exception generically and returning 500 for it, regardless of what actually caused the exception, is a common shortcut. The status code reflects how the error was handled in code, not necessarily where the fault genuinely lies. WHY THIS MATTERS FOR DIAGNOSIS ------------------------------ Per this chapter, "don't assume every 500 automatically implicates the server; reading the actual error body is what tells you whether this is a real server failure or a status code that was simply chosen carelessly." Treating every 500 as proof of a genuine backend problem could send an investigation looking for infrastructure or resource issues when the real cause is a client sending bad input, or a perfectly normal business outcome mislabeled as an error. WHY THIS WORKS AS AN ANSWER ------------------------------ It states the chapter's specific claim and examples (misused validation errors, business-logic outcomes), explains the underlying reason status codes can be chosen carelessly, and connects this to why reading the actual error body - not just the status code - is necessary before drawing a conclusion.