BrianPeek.com

A Compendium of Random Uselessness
in Search

Exception Handlers

Warning.  Rant coming...

I was working on a project last week that included code that looked sort of like this:

public bool SomeMethod()
{
    try
    {
        // do some lengthy, involved, *critical* process that, 
        // if it fails, will cause the rest of the application to fail *forever*
        // as it leaves a required, persisted resource in a corrupted state
    }
    catch
    {
        return false;
    }
}

public void SomeOtherMethod()
{
    SomeMethod();
}
Of course, when I was debugging an issue in this application, SomeMethod was failing, yet I had no idea because the author of the code decided to not only throw away the exception that was being thrown, but not bother to check the return value of SomeMethod after it was called.

So here comes the rant.

Stop it!  Stop doing this!  Stop catching exceptions and either doing nothing with them, or throwing them away!  It's an exception handler!  If you're not going to handle the exception, don't catch it!

I see code that does this way too much,  My other favorite is:

public void SomeMethod()
{
    try
    {
        // big code
    }
    catch
    {
    }
}

An empty exception handler.  Sure, let's run 500 lines of code in a try block and then, if an error occurs, let's not tell anyone.  I bet the people that write these had parents that yelled at them all the time.  In their adult life, they fear the wrath of an authority figure if an error were to occur, so they just throw away the error.

So what's my point in all this?  If I can just get one person to not write a useless try/catch block, I'll be happy.  Look at your code.  Look at your try/catch blocks.  If you're not doing something important with the exception you've caught in your catch block, or you're throwing away the information altogether, please fix it.  Thanks.


		    
	    
Published Mar 25 2007, 02:29 PM by Brian Peek
Filed under:

Comments

 

George Tsiokos said:

When debugging seemly intermittent problems, with exceptions you see not showing the true problem, try enabling debugging of all exceptions: Click Debug, Exceptions, under “Common Language Runtime Exceptions”, click Thrown. You’ll see the catch { }, which probably turns the object in an unknown state (I know Brian knows this but his readers may not).

March 25, 2007 8:02 PM
 

Albert Rosa said:

Thanks for those tips, I find myself to be a culprit to this code crime, and because I am the only one whom works on my projects i expect the possible results, but i keep forgetting about the what if factor!

I will most definate read over my code and attempt to properly handle my exceptions.

Bonus for the "Debug, Exceptions Options!"

March 26, 2007 9:01 AM

Leave a Comment

(required)  
(optional)
(required)  
Add

About Brian Peek

Brian is a Microsoft C# MVP who has been actively developing in .NET since its early betas in 2000, and who has been developing solutions using Microsoft technologies and platforms for even longer. Along with .NET, Brian is particularly skilled in the languages of C, C++ and assembly language for a variety of CPUs. He is also well-versed in a wide variety of technologies including web development, document imaging, GIS, graphics, game development, and hardware interfacing. Brian has a strong background in developing applications for the health-care industry, as well as developing solutions for portable devices, such as tablet PCs and PDAs. Additionally, Brian has co-authored the book "Debugging ASP.NET" published by New Riders, and is currently co-authoring a book titled "10 Coding4Fun Projects with .NET for Programmers, Hobbyists, and Game Developers" to be published by O'Reilly in late 2008. Brian also writes for MSDN's Coding4Fun website, contributing articles on a monthly basis.
Copyright (C) 2008 Brian Peek
Powered by Community Server (Commercial Edition), by Telligent Systems