据我所知,您应该只在实际处理异常时才使用 try/catch,而不仅仅是报告和记录它,然后使应用程序崩溃。否则,您最好只检查有意义的不同场景(例如,如果 sth==null),或者 - 如果您的目的只是记录异常并使应用程序崩溃 - 使用 AppDomain.UnhandledException 。但情况总是如此吗?为什么?
假设以下方法,它接受一个数组并在执行一些数据库和文件系统操作后返回 MemoryStream。
MemoryStream Read (int[] IDs)
{
try
{
using (SqlConnection connection = new SqlConnection(connection_string))
{
connection.Open();
// a bunch of code executing SQL queries & constructing MemoryStream, which is returned at the end of the block
}
}
catch (Exception e)
{
// report the exception to the user & log it
throw; // pointles??
}
}
有多种情况可以被视为异常/不需要的行为,例如:
- 参数 (IDs[]) 为空,
- 无法建立 SQL 连接,
- 无法执行特定的 SQL 查询。
所有这些情况都被认为是异常的,如果您只想记录异常(然后崩溃),仍然将所有内容都放在 try/catch 中可能是不好的做法 - 但为什么呢?在上述情况下,最好的处理行为是什么?完全避免 try/catch,使用 if 语句检查 null 引用(在这种情况下返回 null)并使用 AppDomain.UnhandledException 记录其他所有内容?使用 try/catch,但仍然使用 if 语句检查内部是否有空引用(在这种情况下返回)?还有别的吗?
最佳答案
在代码中添加 try/catch 语句只会导致应用程序崩溃,这种做法效率不高。 CLR 已经为您处理好了。并且您可以使用 AppDomain.UnhandledException 生成适当的信息来诊断原因。
只有在非常特殊的情况下,您必须清理某些内容,比如您不想继续保留的文件,您才应该考虑编写 try/catch。这本身就是一个非常不确定的要求,无法保证您的 catch block 会执行。当异常像 StackOverflowException 或 ExecutionEngineException 这样令人讨厌时,它就不会。或者程序无法自行清理的更常见原因是有人被电源线绊倒或从任务管理器中终止了进程。
关于c# - try/catch 与 AppDomain.UnhandledException 记录应用程序并使应用程序崩溃,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14628015/