我正在看关于可序列化dto的文章c# -数据传输对象。

这篇文章包含了下面这段代码:

public static string SerializeDTO(DTO dto) {
    try {
        XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
        StringWriter sWriter = new StringWriter();
        xmlSer.Serialize(sWriter, dto);
        return sWriter.ToString();
    }
    catch(Exception ex) {
        throw ex;
    }
}

文章的其余部分看起来理智而合理(对于新手来说),但是try-catch-throw抛出了一个WtfException…这不完全等同于不处理异常吗?

结论:

public static string SerializeDTO(DTO dto) {
    XmlSerializer xmlSer = new XmlSerializer(dto.GetType());
    StringWriter sWriter = new StringWriter();
    xmlSer.Serialize(sWriter, dto);
    return sWriter.ToString();
}

还是我错过了c#中错误处理的一些基本内容?它与Java非常相似(减去受控异常),不是吗?... 也就是说,它们都改进了c++。

堆栈溢出问题重新抛出无参数catch和什么都不做之间的区别?这似乎支持了我的观点,试着接球是不行的。


编辑:

只是为了给将来找到这条线索的人做个总结…

try {
    // Do stuff that might throw an exception
}
catch (Exception e) {
    throw e; // This destroys the strack trace information!
}

堆栈跟踪信息对于确定问题的根本原因至关重要!

DO

try {
    // Do stuff that might throw an exception
}
catch (SqlException e) {
    // Log it
    if (e.ErrorCode != NO_ROW_ERROR) { // filter out NoDataFound.
        // Do special cleanup, like maybe closing the "dirty" database connection.
        throw; // This preserves the stack trace
    }
}
catch (IOException e) {
    // Log it
    throw;
}
catch (Exception e) {
    // Log it
    throw new DAOException("Excrement occurred", e); // wrapped & chained exceptions (just like java).
}
finally {
    // Normal clean goes here (like closing open files).
}

在不太特定的异常之前捕获更特定的异常(就像Java一样)。


引用:

MSDN -异常处理 MSDN - try-catch (c#参考)


当前回答

这取决于您在catch块中所做的事情,以及您是否希望将错误传递给调用代码。

你可能会说Catch io。FileNotFoundExeption ex,然后使用替代文件路径或类似的,但仍然抛出错误。

同样,使用Throw而不是Throw Ex可以让你保持完整的堆栈跟踪。Throw ex从Throw语句重新启动堆栈跟踪(我希望这有意义)。

其他回答

抱歉,但许多“改进设计”的例子仍然很糟糕,或者可能会极具误导性。有try {} catch {log;Throw}完全没有意义。异常日志应该在应用程序的中心位置完成。无论如何,异常都会出现在堆栈跟踪中,为什么不将它们记录在系统边界附近的某个地方呢?

Caution should be used when you serialize your context (i.e. DTO in one given example) just into the log message. It can easily contain sensitive information one might not want to reach the hands of all the people who can access the log files. And if you don't add any new information to the exception, I really don't see the point of exception wrapping. Good old Java has some point for that, it requires caller to know what kind of exceptions one should expect then calling the code. Since you don't have this in .NET, wrapping doesn't do any good on at least 80% of the cases I've seen.

你不会想要抛出ex -,因为这会丢失调用堆栈。参见异常处理(MSDN)。

是的,尝试…Catch没有做任何有用的事情(除了丢失调用堆栈之外——所以它实际上更糟——除非出于某种原因您不想公开此信息)。

虽然许多其他答案提供了很好的示例,说明为什么您可能希望捕获重抛出异常,但似乎没有人提到“最终”场景。

举个例子,你有一个方法,你在其中设置了游标(例如一个等待游标),该方法有几个出口点(例如if () return;),你想确保游标在方法结束时被重置。

为此,您可以将所有代码包装在try/catch/finally中。在最后将光标设置回右光标。这样就不会隐藏任何有效的异常,在catch中重新抛出它。

try
{
    Cursor.Current = Cursors.WaitCursor;
    // Test something
    if (testResult) return;
    // Do something else
}
catch
{
    throw;
}
finally
{
     Cursor.Current = Cursors.Default;
}

首先,本文中代码的实现方式是邪恶的。Throw ex将重置异常中的调用堆栈,直到该Throw语句丢失有关异常实际创建位置的信息。

其次,如果你只是像那样接住然后再扔,我认为没有额外的价值。上面的代码示例如果没有try-catch也一样好(或者,考虑到throw ex位,甚至更好)。

但是,在某些情况下,您可能希望捕获并重新抛出异常。日志可能是其中之一:

    try 
    {
        // code that may throw exceptions    
    }
    catch(Exception ex) 
    {
        // add error logging here
        throw;
    }

大多数答案都是关于catch-log-rethrow的。

与其在代码中编写它,不如考虑使用AOP,特别是带有OnExceptionOptions IncludeParameterValue和 IncludeThisArgument