[17.5] Okay, so you're saying exception handling is easy and simple, right?
- Exception handling is not a free lunch. It requires discipline and
rigor. To understand those disciplines, you really should read the rest of
the FAQ and/or one of the excellent books on the subject.
- Exception handling is not a panacea. If you work with a team that
is sloppy and undisciplined, your team will likely have problems no matter
whether they use exceptions or return codes. Incompetent carpenters do bad
work even if they use a good hammer.
- Exception handling is not one-size-fits-all. Even when you have
decided to use exceptions rather than return codes, that doesn't mean you use
them for everything. This is part of the discipline: you need to know when a
condition should be reported via return-code and when it should be reported
via an exception.
- Exception handling is a convenient whipping boy. If you work with
people who blame their tools, beware of suggesting exceptions (or anything
else that is new, for that matter). People whose ego is so fragile that they
need to blame someone or something else for their screw-ups will invariably
blame whatever "new" technology was used. Of course, ideally you will work
with people who are emotionally capable of learning and growing: with them,
you can make all sorts of suggestions, because those sorts of people will find
a way to make it work, and you'll have fun in the process.
Fortunately there is plenty of wisdom and insight on the proper use of
exceptions. Exception handling is not new. The industry as a whole has seen
many millions of lines of code and many person-centuries of effort using
exceptions. The jury has returned its verdict: exceptions can be used
properly, and when they are used properly, they improve code.