So is it best to use try/catch? [closed]

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.