Errors: What Error Handling Is For
An error contains information about something that has gone wrong. This information needs to get to a place in the program where it can be effectively dealt with. While this information is travelling, the program needs to manage its resources properly, and generally stay in a consistent state - some operations may even need to be rolled back to a previous state.
All of this leaves us with some basic principles that will drive everything that follows:
- Information: Get what you need, and don't throw it away, or swamp it in noise.
- Resource Handling: Make sure resources are freed when errors take place.
- Correctness: Errors should not cause an avoidable data loss or crash.
- Practicality: Guidelines have to be usable by programmers in the real world.
To start arriving at a way of dealing with errors that follows these principles, consider where errors happen, and where they are dealt with. Errors can happen inside your code - someone may pass an invalid parameter to one of your methods - but they can also happen in operations many levels below your software. Errors can be dealt with by your code as soon as they arise - but they may be handled by code many levels above that point. And if errors are happening, or being dealt with, far away from your code, this may be in a different language, or even on a different machine.
What are the implications of this?
As far as the information principle goes, we will need to take into account how far an error will be travelling when we are propagating it through code, and try to ensure that information is not lost at any point. Also, we'll need to ensure that resource handling and correctness can deal with problems that arise far below our code, and problems that are dealt with far above our code. But we will need to try and keep the solution practical - an error handling system that programmers subvert in practice is very dangerous, since it makes false guarantees about what a system can and cannot handle.