C# 那么，最好使用try/catch吗？

什么时候最好使用try-and-catch？当我用try-and-catch（有些甚至是-1-me…）回答问题时，我得到了愤怒的回应。我在谷歌上找到了这个，还有这个stackoverflow

我举几个例子：

我有一个下拉列表，当用户选择他的时区时，我正在更新数据库。在另一个应用程序中，我从数据库中提取这个值，并重新计算用户当前的时间和日期。有一个选项是数据库中的数据拼写错误（数据库中的硬编码更改或错误）。在用户日期时间的转换方法中，我使用的是try-and-catch，有人告诉我这是错误的！。我可以使用for循环检查DB中的值，但是每次转换日期时间的成本都会更高

我必须使用以下代码声明XML文件的格式是否正确：

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

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

我看不到任何其他检查xml文件的方法

有时我的应用程序中有一部分我正在写文件。写入文件可能会导致执行，原因有很多，其他一些进程在写入文件或其他文件时正在使用此文件。所以我通常使用以下代码：

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

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

总之，我看到了一些使用try-and-catch和不使用try-and-catch的方法。我看到的文章中有一句话说，如果发生异常，你需要知道它。，但是在处理一般应用程序时，大多数时候我知道会发生异常，但大多数时候我不知道为什么会发生异常，所以我以前无法捕捉到它（就像我写的示例一样），那么，什么时候最好使用“试一试”策略呢

在ASP.NET的同一级别中，该页面有一个错误事件，您可以通过如下方式捕获：

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

---

事件是否与try-catch问题相同？？？

从个人角度来看，我一直认为任何可能出错的事情都会出错，并相应地编写我的异常处理策略。我对其他代码的一个主要错误是，当您遇到一个可能很容易被捕获的未处理异常时，它看起来很混乱，如果是生产代码，则表明您完全不了解程序的工作方式以及可能出现的问题

我的方法可能有些过分，但如果你正在做的事情可能会抛出错误，那么它应该被捕获。我不太喜欢让异常通过堆栈级联并在顶层被捕获——我更喜欢在源代码处捕获它们，记录它们，然后，如果应用程序允许继续，或者最坏的情况是优雅地失败，让用户（或其他开发人员）了解出了什么问题或原因

对于web应用程序，我们使用的方法略有不同。错误（堆栈跟踪等）被记录下来，以便授权人员可以看到它，并向用户提供错误的简化版本，该版本告诉他们出了问题，但没有说明具体情况

---

那是我的两便士。我不确定这种方法是正确的还是错误的，但它对我们有效，并帮助我们生成更健壮的代码。

对您使用try/catch-in的批评不是针对一般情况下使用try/catch，而是针对特定的使用方式

• 您应该捕获异常对象（即，使用catch（SomethingHappenedException e），以便获得有关出错原因的可用信息

• 您应该捕获特定的异常，而不是所有异常。在DateTime示例中，我会尝试找出每次调用可能引发的异常。然后，我会尝试找出是否有某种方法可以在不使用异常的情况下捕获这些错误-该代码中可能捕获的异常之一是ArgumentNullExce这是一个例外，但我应该能够通过首先检查我没有传递空区域id来在流中处理这个问题。
  最后，如果无法在程序的正常流程中处理这些情况，我将捕获可能发生的特定异常，并尽可能接近异常源

---

这看起来可能需要更多的努力，但它确实节省了您调试的时间！

我想我可以总结一下人们过去在try…catch上遇到的问题，并提供一些清晰的信息，这对您将来会有所帮助

前两个示例是由数据验证错误引起的。在将数据传递到转换函数（示例1）或尝试编写XML文件（示例2）之前，应检查数据是否存在已知的验证错误

异常处理有很大的开销，因此只有在绝对必要时才会发生。try…catch模式是为处理意外（异常）错误而设计的，而不是标准的数据验证

示例3几乎是正确的用法。在这种情况下，可能会发生一些您无法准备的意外情况，例如IOException。捕获特定异常被认为是不好的形式，因为它可能导致多个捕获块或丢失处理。捕获通用异常对象更好，并且异常处理也更有效de可以确定并处理异常的确切类型

您的try…catch块也应该封装streamwriter，因为每个方法只有一个try…catch是最佳实践。如果您使用try…catch，它必须始终包含异常处理代码。空catch块或空finalize块是不好的形式，对代码或试图在您之后维护它的任何人都没有帮助

    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
    }

---

希望所有这些都有助于回答一些问题并澄清问题。

例如，查看代码会很有帮助。如果不更具体地了解您在做什么，很难发表评论

例如，该代码的问题在于它完全隐藏了任何错误条件。当然，我们会发现xml文件是好是坏……但是为什么xml是好是坏呢？我们不知道。不是try/catch不好，而是整个事情都不好