...no matter how comprehensive your testing is (and most isn't, since there's almost always a bias towards testing things which should suceed rather tha

...no matter how comprehensive your testing is (and most isn't, since there's almost always a bias towards testing things which should suceed rather than testing things which should fail) it will never cover as many combinations of strange inputs and obscure environments as your code is likely to encounter in production. Poorly tested code has more bugs per line; and when you're faced with the likelihood of a large number of bugs per line of code — whether it's due to poor testing, poor developers, or merely because the code is difficult for reviewers to understand — it's important to minimize the amount of bug-prone code. The shortest possible error-handling path is "exit(1);". This whole section is complete nonsense. Whether you choose to exit(1) or return 400 Bad Response, you should still write tests that assert you do so correctly. The difference between the two options is that clients who receive a 400 response at least know the problem is at their end. Perhaps they can handle it automatically or perhaps they can flag it to a user or whatever. Turning everything into a 500 is just a poorly-designed API.