Question

So I am recently writing a relatively complex application written in C# that performs an array of small tasks repeatedly. When I first started the application I realized that a lot of the code I was typing was repetitive and so I began encapsulating the majority of the app’s logic into separate helper classes that I could call as needed.

Needless to say the size of my app (and amount of code) was cut in half. But as I was going through I noticed something else in my application that seemed to be repetitive and looked like it could be improved.

Now most of my methods in my helper classes are either making a HttpWebRequest or performing save/delete operations on files. Having said that I need to handle the possibility that eventually the call won’t complete, or the file can’t save because there isn’t enough space, or whatever. The problem I’m running into is that I have to keep writing try/catch statements every time I call one of the methods. On top of that I have to retype the error message (or Eventually a status message. I would like to know when it succeeds as well).

So here’s kind of a snippet of what I have to type:

  try
  {
     ItemManager.SaveTextPost(myPostItem);
  }
  // Majority of the time there is more than one catch!
  catch
  {
     //^^^Not to mention that I have to handle multiple types of exceptions 
     //in order to log them correctly(more catches..ugh!)
     MessageBox.Show("There was an error saving the post.");
     //Perform logging here as well
  }

From what I have concluded so far is:

• To me this is overkill having to write this over 50 times for my app.
  Sounds like I should be including this in the helper class and
  include the full set of catches.
• But how could I know the result? I was maybe thinking of returning a
  string that contains the error/success message.
• Really for these types of methods it doesn’t require the method from which the helper method is being called from to enclose it in a try/catch block.

Is this approach correct? Is there another way of doing this? Should I be using a try/catch in the calling method at all? Since this kind of my first shot at this I would really like to hear what others who have handled this scenario have to say.

Answer 1

I think putting the try/catch in the method you are calling is perfectly fine. You can return error/success codes to the calling code in a variety of ways. .NET and c# handle enumerations nicely, so you could have ItemManager.SaveTextPost(myPostItem, out errorCode); where errorCode would be an enumerated value that would let you know if any problems occurred. It could also be as simple as having the method return a bool true if successful, false if otherwise. There are many ways that you could handle that issue, but as far as I’m concerned putting the try/catch in the method is the preferable way of doing things.