professional programmer for more than
a few days knows that many developers
will always write the code they are
most interested in, or pressured to
deliver first, which is not the error-and exception-handling code, nor is
it test code, nor documentation, the
latter two of which I have already harangued readers about, ad nauseam.
What management and the rest of
the team want, is “the code,” and
what most people see as “the code”
is only the part of it that explicitly
does the job you are expected to do.
It’s not even the demands of others
that cause this narrow focus; it’s
often just that the error-handling
parts are not as interesting to the person writing the code as getting a result.
It would seem that many programmers
just want to move those bits, munge
that data, and show pictures of cats.
In point of fact we have a clear indication of the importance programmers
put on the error-handling components
of the code by this finding: “Error handlers with TODO or FIXME in the comment.” Personally, I prefer XXX, as it reminds me of my time in Amsterdam in
the early 1990s, and unless you’re working in certain industries—industries
that might also serve photos, and might
still serve photos of cats—you’re unlikely to find XXX as a variable in the code.
We can look at the fact that the Java
compiler forces programmers to catch
all the unchecked exceptions in one of
two ways. If we are charitable—and KV
is the heart and soul of charity—we assume the Java language and compiler
developers are simply helping programmers make fewer mistakes and make
sure their code not only does what it is
meant to do, but also acts appropriately
when things go awry.
If we are less charitable, or perhaps
more honest and realistic, we see this en-
forcement quite differently: as a naked
attempt to control programmers and
make them do what the language and
compiler people thought was right at the
time. “Programmers don’t do proper er-
ror handling. I know, we will MAKE them
handle errors, or their programs won’t
compile at all!” I believe this is said in the
voice of an overbearing schoolteacher.
“You will dot your i’s! You will catch all
exceptions!” Except that unlike dotting
an i, there are ways to skate around han-
dling the exception that was meant to be
handled. In a rush? Well then, just add
a TODO or FIXME or XXX in the com-
ments and move on. You’ll come back to
it later ... of course you will.
Both sides are a little bit wrong in
this case. We can all point fingers at the
person who leaves a trail of FIXMEs in
the code, but who among us is without blame in that regard? We can also
blame the pedants who thought that
forcing every exception to be caught
was doing us a favor. You can never
discount the human element in programming. For everything you try to
force on someone, there is something
they will work to avoid if at all possible. Tool builders need to understand that the people who use their
tools are often trying to get a very narrow job completed with a minimum
amount of effort. Was it wrong to add
the forced exception handling into
the tool? Maybe and maybe not. In the
hands of someone with the time and
inclination to do the right thing, these
errors are a welcome way of finding
problems that they do have to handle.
Clearly, in the hands of a large percentage of programmers who work on
some of the most complex systems yet
devised, the feature is actually a nuisance, and it is likely time to rethink
how this particular exception ought to
Productivity in Parallel Programming: A
Decade of Progress
John T. Richards, et al.
Looking at the design and benefits of X10
Going with the Flow
Peter de Jong
Workflow systems can provide value
beyond automating business processes.
The Challenge of Cross-language
Interfacing between languages
is increasingly important
George V. Neville-Neil ( email@example.com) is the proprietor of
Neville-Neil Consulting and co-chair of the ACM Queue
editorial board. He works on networking and operating
systems code for fun and profit, teaches courses on
various programming-related subjects, and encourages
your comments, quips, and code snips pertaining to his
Copyright held by author.
Available for iPad,
iPhone, and Android
Available for iOS,
Android, and Windows