C# Nested Try Catch statements or methods?

2019-04-18 08:23发布

Simple best practice question.

Should you nest try catch statements or just use methods.

For instance, if you have a method that opens a file does work and closes the file, you would have the open and close outside the try catch, or rather the close in the finally block.

Now if your open method fails, the method would assert right? So should your wrap that in a try catch block or should that be called from another method, which in turn as a try catch block?

8条回答
我欲成王,谁敢阻挡
2楼-- · 2019-04-18 08:28

Now that we have lambdas and type inference and some other stuff, there's an idiom that is common in other languages which now makes a lot of sense in C#. Your example was about opening a file, doing something to it, and then closing it. Well, now, you can make a helper method which opens a file, and also takes care of making sure to close / dispose / clean up, but calls out to a lambda you provide for the "do stuff" portion. This will help you get the complicated try/catch/finally dispose/cleanup stuff right in one place, and then use it over and over.

Here's an example:

public static void ProcessFile(string filePath, Action<File> fileProcessor)
{
  File openFile = null;

  try
  {
    openFile = File.Open(filePath); // I'm making this up ... point is you are acquiring a resource that needs to be cleaned up after.

    fileProcessor(openFile); 
  }
  finally
  {
    openFile.Close(); // Or dispose, or whatever.
  }
}

Now, callers of this method don't have to worry about how to open the file or close / dispose of it. They can do something like this:

Helpers.ProcessFile("C://somefile.txt", f => 
 {
   while(var text = f.ReadLine())
   {
     Console.WriteLine(text);
   }
 });
查看更多
Juvenile、少年°
3楼-- · 2019-04-18 08:35
try 
{
  ----
}
catch
{
   try
      {
           ---
      }
   catch
      {
        ---
      }
}
查看更多
劫难
4楼-- · 2019-04-18 08:37

Most of the time I would break up the nested try/catch blocks into functions. But I have sometimes written code to catch and log all uncaught exceptions thrown by my application. But what if the logging code fails? So I have yet another try/catch around that just to prevent the user from seeing the default .NET unhandled exception dialog box. But even this code could very easily be refactored into functions instead of nested try/catch blocks.

try
{
    try
    {
        DoEverything(); 
    }
    catch (Exception ex)
    {
        // Log the exception here
    }
}
catch (Exception ex)
{
    // Wow, even the log is broken ...
}
查看更多
萌系小妹纸
5楼-- · 2019-04-18 08:38

In the context of a method that opens a file I would use a using statement vs a try catch. The using statement ensures that Dispose is called if an exception occurs.

using (FileStream fs = new FileStream(file, FileMode.Open))
{
    //do stuff
}

does the same thing as:

FileStream fs;
try
{
     fs = new FileStream(file, FileMode.Open);
     //do Stuff
 }
 finally
 {
        if(fs!=null)
           fs.Dispose();
 }
查看更多
啃猪蹄的小仙女
6楼-- · 2019-04-18 08:38

How about where you have related code that doesn't necessarily belong in a separate function of it's own right? Would this then be correct?

try
{
  // Part 1 Code Here

  try
  {
    // Part 2 Code Here
  }
  catch (Exception ex)
  {
    // Error from Part 2
  }
}
catch (Exception ex) 
{
  // Error from Part 1
} 
查看更多
再贱就再见
7楼-- · 2019-04-18 08:44
//create a switch here and set it to 0 
try
{
    DoChunk1(); 
    //looks good. set the switch to 1
}
catch (Exception ex)
{
    // Log the exception here
}

// check the switch, if it is still zero at this point then you may halt your program here; else set the switch back to zero and execute your next try catch statement. totally agree with breaking them down as mentioned above

try { DoChunk2(); //looks good. set the switch to 1 } catch (Exception ex) { // Log the exception here }

查看更多
登录 后发表回答