-1

I'm curious to find out what the best practice is for caught exceptions that aren't used. The irony is that this is going against best practice in the first place. I've found myself in a position to be doing this, perhaps it's just my inexperience, but I'm wondering what is commonly done.

I've written a small console application that grabs list information from one Sharepoint site to share it on another farm. The function in question queries the list into an XElement and I am catching any errors along the way. Here is the snippet.

...
    try
    {
       return lists.GetListItems("Global Announcement", null, null, viewFields.GetXmlNode(), null, null, null)
                 .GetXElement().Elements().First().Elements().First();
    }
    catch (Exception ex)
    {
        throw;
    }
}
catch (Exception ex)
{
    ErrorLogging.SaveErrorToEventLog("Encountered an error when attempting to connect: ", ex);
}

I was advised by a senior to use just the throw for the inner exception to keep the stack information in proper order. In cases like this I'm curious to find out what the best practice is for the Exception ex or if breaking the best practice of try catch in the first place should just never happen?

Matt Ball
  • 354,903
  • 100
  • 647
  • 710
MacSalty
  • 1,212
  • 4
  • 14
  • 21

1 Answers1

3

Catching an exception just to rethrow it is pointless and just causes your code to go bigger and become slower.

On the other hand, if you do catch and don't rethrow you should always log it somewhere, as you appear to be doing correctly in your outer handler.