Current Error Handling
- Memory allocation error when using new
- File open error
- Out of bounds array subscript
- Division by zero
- Function PreConditions not met
What we do now
Most commonly, error-handling code is interspersed throughout a system's code.
- assert (condition)
if the condition is false, the program terminates
- Ignore the error or try to handle the error internally
devastating for real products, but maybe okay for your own software
- Set an indicator for other code to detect (e.g., return a flag)
- Issue an error message and exit
Error processing is in the immediate vicinity of the code that caused
the error (easy to find)
Code becomes polluted with error processing and the code becomes
difficult to read and understand.
Application code does not get to handle errors in the way that it
considers most appropriate
Layered and Encapsulated Code
The crux of the issue is what low level code (or aggregated objects)
should do when an error is detected. How should it handle them?
The answer is -- they shouldn't
Low level code supplies services for the high level code.
Objects supply services for their users.
Since the low level code (or aggregated objects) can't know how it's
being used, it can't and shouldn't decide how to handle errors.
It should only detect them and inform the high level code (object
users) that the error occurred.
How do we do that?
Last Modified: Monday, 28-Aug-2006 10:16:05 EDT