[prev] [thread] [next] [lurker] [Date index for 2007/01/26]
On Fri, Jan 26, 2007 at 06:03:22PM +0200, Yossi Kreinin wrote:
> And you don't even need to work hard to make your program deny the crash -
> just develop your programs on Microsoft Windows (tm) using Microsoft Visual
> C++ (tm)! Look how easy it is:
>
> 1. "Structured exception handling" (the __try/__except kludge) traps access
> violations, leaving your program alive.
> 2. C++ exception handling (the catch-everything try/catch(...) kludge) also
> does that.
> 3. I'm not sure if it's MFC or, worse, the underlying API such as
> GetMessage, but when you handle messages, access violations may also get
> trapped.
http://thedailywtf.com/Articles/Catch_and_Release.aspx
And, if you regularly read the DailyWTF, you'll see that incompetant
exception handling is a regular occurance. At work we use C# and I
constantly see code like:
try
{
// do some stuff
}
catch (Exception)
{
throw new UnrelatedException();
}
Of course, any information about the original exception is completely
lost and I can't access it at all. Since we are writing a test tool
it is rather important to have details about exactly why things go
wrong. My favorite example of this crap:
try
{
// Parse some XML
}
catch (Exception)
{
return null;
}
So, instead of having access to the very, very useful information in the
.NET XmlException (like, say, what went wrong with parsing and what line
it was on..) is completely lost and instead I just get to know it
failed. Not to mention what happens if a null reference, or an out of
memory error, or whatever other kind of exception is thrown? My only
choice is to log "unable to parse the XML" because that is all I know.
What is the purpose of all this exception handling again? And this code
is written by people who should know better.
-D
--
/--------------- - - - - - -
| Dan Noe, freelance hacker
| http://isomerica.net/
Generated at 23:01 on 06 Feb 2007 by mariachi 0.52