Many programming languages nowadays have concept of Exception Handling: Constructs where the normal program flow is redirected based on signals or events. Generally, such contructs are intended to perform error handling rather than letting the program terminate abruptly.
Let's take an example in e.g. Java. Imagine that this code is part of a program that produces some popular report for the finance department:
public void doSomething() {
SomeObject so = new SomeObject();
try {
int status;
so.setSomething("foo","bar");
status = so.someMethod("Hello World");
if (status == SomeObject.OK) {
String response = so.getResponseDetails();
so.saveResponse(response);
}
} catch (IOException e) {
e.printStackTrace();
}
}For the untrained eye, this code looks correct.
But look again. Can you see why this piece of code is a undiscovered problem waiting to catch you out?
The code example uses the exception handling structure of the language to catch errors. But the it is abused to the extent that the exception handling does not actually handle the exception. The exception is simply written out (usually to a log file that nobody reads), AND THEN COMPLETELY IGNORED! Only a confused soul would call this exception handling.
I call it exception non-handling because it does not handle the exception. It does not take any remedial action. It just makes the program continue as if nothing had gone wrong. Just printing out the stack trace may be useful, but unless we can rely on a sharp-eyed, lightening fast operator to alter the program flow at run-time, the program will continue regardless, and probably give the wrong numbers in the resulting report.
And because the program did not fail, there will be no indication that the numers reported are incorrect, so the finance department will make desicions based on those numbers.So those decisions may be wrong as a result.
In real life, the failure will go undetected until:
- Somebody looks at the log containing the stack trace
- Somebody examines the result of the program (e.g. a report) and notices something odd
- Somebody performs a source code review
When you add up all the evidence, this speaks volumes about the programmer's attitude to error handling and attention to detail: Something is badly wrong here. And it will stay bad for a long time.
Ironically, this error would not have occured if the dodgy exception handling was removed: The programmer's half-baked attempt at exception handling introduced the problem.
Imagine if the exception "handling" had been absent: The program would have failed with an error message and the cause would have been obvious. And nobody would have been misled with erroneous reports.
WWPL ? (When Will People Learn?)
| < Prev | Next > |
|---|
