最佳实践异常处理

时间:2017-01-30 12:58:53

标签: c# exception-handling

来自here,我不确定异常处理。 MSDN显示了第一种方式。第二个也可以吗?它更短,应该产生相同的输出。

问题:我可以使用第二种方式而没有任何副作用吗?

try
{
    string s = null;
    ProcessString(s);
}
catch (ArgumentNullException e)
{
    LogError(e.Message);
}
catch (Exception e)
{
    LogError("Error");
}

try
{
    string s = null;
    ProcessString(s);
}
catch (Exception e)
{
    LogError((e is ArgumentNullException) ? e.Message : "Error");
}

2 个答案:

答案 0 :(得分:1)

首先,当你有未知异常时记录“错误”字符串是非常糟糕的做法。您应该记录错误详细信息 - 消息,内部异常等。这就是为什么日志记录框架提供接受将记录的Exception对象的方法。

接下来,只有在处理不同的时,才能捕获不同类型的异常。在您的情况下,两种情况都有简单的错误记录,因此您无需将ArgumentNullException与其他异常区分开来:

try
{
    ProcessString(null);
}
catch (Exception e)
{
    LogError("Failed to process string", e);
}

最后 - 不要编写自己的日志框架 - 看看NLog,log4net等。

另请注意,通常您只应处理高级别异常。例如。如果您在尝试执行某项业务操作时遇到ArgumentNullExceptionIndexOutOfRangeException,则向用户显示这些低级别异常并不好。您通常将它们包装在自定义的高级异常(例如DataMigrationException)中并稍后处理它们

答案 1 :(得分:0)

答案确实是“它取决于”。

这并不是那么糟糕,但更具体的例外更好。当您更具体时,这意味着您实际上更明确地了解您的应用程序正在尝试做什么以及对其进行更多控制。您应该真正处理您期望的异常,并将其他所有内容视为错误。

如果你专门捕捉到你知道代码块或方法可以抛出的异常,那么你实际可以恢复的可能性更高,而不仅仅是记录和希望最好的。