[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] Re: Re: Changes in 2634

From: Joseph Galbraith <galb_at_vandyke.com>
Date: 2005-02-08 17:18:59 CET

>>I do not believe that the long term stability or quality of the
>>product is served by catch(...) blocks, particularly when their role
>>is to conceal bugs in other parts of the same application.
>
> No debate there, bugs should not be concealed. But nor should they be
> allowed to cause an explorer crash. The catch(...) would be OK if it
> threw out a warning rather than silently hoovering up the evidence.

I have made great efforts to remove all catch(...) code
from the code I write and maintain... and talked and
coerced and done anything necessary to get the programmers
I work with to not use them.

The phrase I use around the office is "catch(...) is evil."

Why?

Because I don't get a Dr. Watson dump if someone puts in
a catch(...). And a warning doesn't cut it, in terms
of tracking down the bug.

In addition catch(...) papers over a corrupt heap as well as
bad data. Or any of a bazillion other things that could go
wrong to cause the exception in the first place and are still
wrong after the catch(...).

It isn't possible to reliable recover from an arbitrary
exception. Period.

Better to just get it over with now, as close to naughty code
as possible so it is easier to figure out what went wrong.

Now it seems like I saw mentioned that you have some crash telemetry
generating machinery... if that were hooked into the catch(...),
and I still got my dump even if the program didn't crash, it
would make catch(...) about -.25 instead a of a -1 for me (not
that I have any vote here.) But you still have the problem
that you don't really know what caused the exception... and
so you don't know if a corrupt data structure is still lurking,
waiting to cause a crash someplace else.

Just my $.02 worth.

Thanks,

Joseph

PS. I do have one catch(...) in my code: Around our call
to FormatMessage(). I added it with great reluctance, but
in this case, the crash is probably due to a bug in a piece
of code doing logging not specifying parameters correctly.

In this case, I decided that I most likely knew the cause,
and that the value of the logging being done was higher than
the risk that something else caused FormatMessage() to
crash.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Feb 8 17:19:33 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.