So is it best to use try/catch?

Question

When is it best to use try and catch? I've gotten angry responses when I answered questions using try and catch (some even -1 me...) I Googled it and found this article and also this stackoverflow question.

I give some examples:

1. I have a drop down list with time zone IDs, when the user selects his time zone I'm updating the database. In other application i'm pulling this the value from the DB and recalculate the user current time and date. There is an option that the data in the DB is misspelled (hardcoded change in the DB or bug). In the conversion method of the date time of the user I'm using try and catch, which some people told me it is wrong!. I could check the value from the DB using for loop but it is costing more for each time I'm converting the date time...

2. I have to declare if an XML file is well formatted using this code:

   protected bool IsValidXML(string xmlFile)
   {
       try
       {
           XmlDocument doc = new XmlDocument();
           doc.LoadXml(xmlFile);
       }
       catch(XmlException ex)
       {
           ///write to logger
           return false;
       }
       return true;
   }
   

   I can't see any other way to check the xml file.

3. Sometime I have a part on my application I'm writing to a file. writing to a file can cause exeprtion for many reasons , some other process is using this file while writing or other. so usually I'm using this code:

    using (StreamWriter w = new StreamWriter(fs))
    {
        try
        {
            w.Write("** (Line) " + someValue + " **" + Environment.NewLine);                       
            w.Flush();                       
        }
        catch(IOExeption ex){}
        finally
        {
            w.Close();   
        }
    }
   

In conclusion I see some ways to use try and catch and ways to not use. The one sentence in the article I saw said If an exception happens, you need to know about it. , but when dealing with a generic application most of the times I know that an exception will happened but most of the times I can't really know why it happened so I can't catch it before (like the examples I wrote) , So when is best to use the try and catch

In the same level in ASP.NET the page has an Error event that you can catch like so:

this.Error += new EventHandler(Page_Error); //this = instance of System.Web.UI.Page

Is the event is the same as try catch problem??

Answer 1

How you handle an exception depends on the nature of the exception, and on the context in which it occurs.

Smart people have written excellent articles about the subject, and I certainly can recommend:

• How to Design Exception Hierarchies by Krzysztof Cwalina
• Vexing exceptions by Eric Lippert
• API Design Myth: Exceptions are for "Exceptional Errors" by Krzysztof Cwalina

About your examples:

In case 1 you might indeed want to be defensive. But then make sure that you do something sensible in that catch block.

Case 2 looks reasonable, but you're reading the XML document only to throw it away. Would it no make more sense to also process it?

In Case 3 you are using try finally, which is definitely not the same thing as try catch. In your specific example you don't even need it, as the using statment is already making sure the file will be closed.

Answer 2

From a personal perspective I've always assumed that whatever can go wrong, will go wrong and write my exception handling strategy accordingly. One of my major bugbears with others code is when you get an unhandled exception that could easily have been trapped - it looks messy an if it is production code then it shows a complete lack of knowledge of how your program works and the things that might go wrong.

My approach might be overkill, but if something you are doing can throw an error then it should be trapped. I'm not a huge fan of letting exceptions cascade through the stack and being caught at the top level - I'd prefer to trap them at source, log them and then, if the application allows it continue, or at worst fail gracefully and leave the user (or other developers) understanding what has gone wrong or why.

With web applications we use a slightly different approach. The error (stack trace etc) is logged, so that authorised people can see it and the user is given a cut-down version of the error which tells them something has gone wrong but not the specifics.

Thats my two pence anyway. I'm not sure if the approach is right or wrong, but it works for us and helps us to produce more robust code.

Answer 3

The criticisms of your use of try/catch in this answer were not against using try/catch in general, but against that particular way of using it.

• You should capture the exception object (i.e. use catch(SomethingHappenedException e) so you get the available information about what went wrong.

• You should catch specific exceptions rather than everything. In the DateTime example, I would try to find what exceptions might be thrown by each of my calls. I would then try and figure out if there was some way of trapping these errors without using exceptions - one of the exceptions that might be caught in that code is a ArgumentNullException. That's an exception, but I should be able to handle that within the flow by first checking that I'm not passing a null zone id.
  Finally, if it's not possible to handle those cases within the normal flow of the program, I catch specific exceptions that might plausibly occur, and as closely to the source of the exception as possible.

It might seem a bit more effort but it does save you on debugging time down the road!

Answer 4

For example 1, it would be helpful to see code. It's hard to comment without a more concrete idea of what you're doing.

For example 2, the problem with that code is that it completely hides any error condition. Sure, we'll find out if an xml file is good or bad... but why is the xml good or bad? We can't know. It's not that try/catch is bad: it's that the whole thing is being written at the wrong level. Just write code to read the xml file, and have your error handling around that code.

For example 3, you are again swallowing any helpful exception information, and in fact not doing anything with your try/catch at all. The .Close() call in your finally blocks is completely unecessary, because closing your stream is entirely handled when the stream is disposed by the using block.

In summary, I think what you need to learn here is not that try/catch blocks are bad. It's that swallowing exception information is bad.

Answer 5

I think I can sum up the issues people have had in the past with your questions on try...catch, as well as provide some clarity that should help you in the future.

Your first two examples are caused by data validation errors. The data should be checked for known validation errors before being passed to the conversion function (example 1) or trying to write an XML file (example 2).

There is significant overhead in exception handling, so it should only occur when absolutely necessary. The try...catch pattern is designed for handling unexpected (exceptional) errors, not standard data validation.

Example 3 is almost proper usage. It is a situation where there are unexpected things that may occur that you cannot be prepared for, like an IOException. Catching a specific exception is considered bad form as it can lead to multiple catch blocks or missed handling. Catching the generic Exception object is better, and the exception handling code can determine and deal with the exact type of exception.

Your try...catch block should encapsulate the streamwriter as well, since it is best practice to only have one try...catch per method. If you use try...catch, it must always contain exception handling code. Empty catch blocks or empty finalize blocks are bad form and are not helping the code or anyone who is trying to maintain it after you.

    try
    {
       using (StreamWriter w = new StreamWriter(fs))
       {

           w.Write("** (Line) " + someValue + " **" + Environment.NewLine);                       
           w.Flush();                       
       }
    }
    catch(Exception ex)
    {
        //exception handling code here
    }
    finally
    {
       //any clean up code here. The using statement makes it unnecessary for the streamwriter
    }

Hope all of this helps answer some questions and bring some clarity to the issue.

Answer 6

In my experience, any external operations (such as interacting with a db or file system, or using 3rd party components) should have a try catch block around it. In my own code, I always try to put in guard clauses to methods to limit the number of exceptions my own code produces, if for example you know that the database won't accept a null First name on a person object, add a guard clause should be added to the top of any save method.

In short, don't rely on exceptions to tell you where your code is going wrong, rather try to cut down the likelyhood of an exception first