Some notes on the way people create taxonomies of errors.
TODO(PMM)
TODO(PMM)
TODO(PMM)
TODO(PMM)
TODO(PMM)
from MartinKuhl2015
- only one type, essentially (equivalent to all types ;-) ?)
- a program state is reached, whose salient environment "ORACLE is down" is unique
- a program state is reached whose category is unique but whose environment is variable "table or view %s not found"
- The system implementation failed, e.g. out of memory.
- Something passed to the function failed, e.g. an exception thrown from a callback.
- The function detected an inappropriate environment, e.g. null pointer parameter.
- Data structure bounds prevent completion, e.g. pushing a full queue.
- The disappointment is expected, e.g. popping an empty queue.
- A function is unsuccessful because it is called out of contract. When a function is called out of contract the result is undefined behavior and there is no way to recover.
- The operation a function promises to perform is not always successful, e.g., because the outcome depends on values passed to the function and/or the state of the system. The unsuccessful outcomes are, however, part of the function's abstraction and can be determined when designing the interface without considering implementation details. This kind of failures is called semantic failures below. Semantic failures are best dealt locally using a status indication provided by the function.
- A function may encounter disappointing outcomes from operations it uses internally and which are not part of the abstraction. The details of the operation are outside the immediate control of the caller. This kind of failures is called system failures below. System failures are in this sense rather unrelated to the function's actual operation. System errors are best dealt with using exceptions.
Where some systems have defined exceptions and they were enthuisastically used.