There are 3 axioms to guides programmers to errorhandling and robustness.
With requests: Do your very best to comply, no matter what
In error messages: Be humble and ask for guidance
With exception, return code and parameter handling: It should work, even on the far side of the moon
Here are som illustrations to set the mode of thinking:
Imagine that you are a borne again religious, and that your deity speaks to you. If he ask of you to perform a task for him, you don't reply with "Sod off. You forgot to specify x, and i'm busy doing some important very important and complicated garbagecollection" Instead you assume that he knows far more than you. You ask for guidance and do your best to figure out how to accomplish the task, because you know it serves a higher purpose. That is exactly the attitude you should use when programming new smart functionality to this system. The user is God and you do your best to interpret the command and wish of the user. If you lack something, you do your best to get a decent result anyway, from the information you have. Always assume that the user has a grander agenda in mind. If you really can't do it, you ask humbly for guidance.
Imagine that your code control a valve to open the water tap. You have a pressure sensor and a Thermossensor. The user asks you to turn on the water, but for some reason the sensors don't work, so you don't know if the water is too hot or how much to open the valve, not to splash the user. A lazy programmer would reply with an error message like “sensor x timed out. Please specify valve setting (from 0 – 255)” Imagine then that you are the user, and that the house is on fire and you need the water to put it out. You probably don't really care about sensors. You have a higher goal, that might be beyond what the programmer could imagine. In fact when you are the programmer, its best if you imagine, that the unit you are programming, will be installed in a spaceship, that might crash on a far side of some moon. No chance of fixing it remotely or in the next update. No programmer at hand. So it simply has to work as best it can. If some functionality falls out, well some parts might still work.
Error messages to the user should be avoided when possible. Users should only be informed that a requested function could not be performed. if needed additionally: because of a script error of some kind etc. Users are NOT supposed to report errors, The error handling system does that. When a situation occur that would constitute an error, think of ways to deal with it without involving the user, so that the users requests are served best. Error handler must work even when the database is off-line.
Errors are handled in a standardised way throughout the system.
1 minor (script error) 2 function fatal error (eg. device failure) 3 section fatal error (eg. central component faliure) 4 system wide reduced functionality (eg. data base failure) 5 system fatal error
For PHP Internally in the node server: