| Cars are actually a good example of how errors should work. Errors should give appropriate information to diagnose and solve the problem to the stakeholders. So a car may have different lights/states from "low fuel", "tire pressure", "door ajar" - to "service soon" to "failure imminent". These are all meant as calls to action by a typical driver, including potentially having them escalate to a mechanic/service center. It is the mechanic can read off the status codes of the car computer to help further diagnose the issue. A 401 in a browser indicates how the _browser_ can react to insufficient authentication, via the instructions in WWW-Authenticate headers. The majority of status codes provide very little instruction to the browser, and provide even less to the end user. "400 Bad request" doesn't include instructions on how the browser can fix the query or form data being submitted, nor is there a process to inform the originator that they are linking to a location incorrectly. To the end user, a 400 error is even more worthless - there is nothing about a 400 that gives instructions on how to get the problem repaired. The trend for development is to define errors which describe each failure case and to delegate those errors up. A robust system however needs to think about failure cases holistically and along with their recovery steps. Once you do this you typically have significantly fewer errors, because you have identified the appropriate recovery steps. |