Re: need argument for try catch blocks
"Christopher" <cpisz@austin.rr.com>
I've got my self an old c style programmer reviewing my code at work.
Being C programmer helps little using C++, it is more like a hindrance. To
be good in C++ you shall unlearn very much.
I've already discovered a plethora of bugs in that exceptions are
getting thrown from native code, the windows API, and our own code and
never handled.
Unhandled exception is not a coding mistake but part of fundamental design.
The project shall have an exception handling policy that makes it clear
where the boundaries are and where to catch. Making stuff obvoius. And
wothout no wonder you have chaos.
However, in my code reviews, I've got items about "unecessary try
catch blocks."
Naturally. Catch supposed to be very rare. And restricted to library border
and high level functions.
I really don't know why it is even worthy of putting in
a code review. Maybe he is thinking efficiency or readability?
Likely just know how code is supposed to be. The norm is to be
exception-neutral. Possibly with some odd throws. If there is a catch, the
content shall make it obvious that it is necessary. If there is doubt it
shall not be there.
My point of view is that when your dealing with a huge project with
poor documentation, it is better to always surround anything that
throws with a try catch block, even if it seems unecessary.
Huh? Hodgepodge will not make anything better. Adding lines without a clear
and sensible reason just increases the mess. For exceptions it is even
more so, as they propagate finely. So the only code that catch is the one
that knows too well what it expects and what to do about it. And why,
obviously.
I can't
count the number of hours I've spend debugging code that was bugged
because of no error checking.
Exceptions make it quite impossible to "not check" in the C sense, so your
case can not apply. The most that can happen the program is hit with
exception no one thought to handle, where you get terminate() as the best
default.
But to have anything better you shall be able to show the point between
emitter and main() where it was supposed to do anything else to call it a
coding bug. Just inserting random try blocks at random places is not that.
The code changes all the time and a
catch that might never get hit, could get hit after many edits. If
nothing else it seems like a good way to assist the poor guy
debugging. It says to me, "Hey an error could occur here!"
Care to explain how it says that at the random catch site? And how you can
state it is "error", when upstream someone could have the proper catch?
My problem is in convincing my peers.
No wonder.
I cannot formalize my argument.
Don't formalize then. Just try to make your case, say here. In a real sense.
Show some "broken" code and your "fixed" version. Explain the difference,
showing the situations when it is better. Then be ready to defend your
position. :)
Is there an source with clout that will back my argument up?
We will see as soon as "argument" is actually presented.
Or
perhaps someone can put into better words what I am describing? Or am
I just wrong?
Most likely the latter, but do make your case, so can learn either this or
that way.