处理异常时.Net中的常见编程错误？ [关闭]

Question

您在处理异常时遇到过哪些最常见的错误？

似乎异常处理可能是学习如何在 .Net 中“正确”做的最难的事情之一。特别是考虑到Common programming mistakes for .NET developers to avoid? 的当前排名第一的答案与异常处理有关。

希望通过列出一些最常见的错误，我们都可以学会更好地处理异常。

Answer 1

您在处理异常时遇到过哪些最常见的错误？

我能想到很多。

首先阅读我关于将异常分类为烦恼、愚蠢、致命和外生的文章： p>

http://ericlippert.com/2008/09/10/vexing-exceptions/

一些常见错误：

• 无法处理外部异常。
• 未能处理令人烦恼的异常。
• 构造方法会引发令人烦恼的异常。
• 处理您实际上无法处理的异常，例如致命异常。

• 处理隐藏代码中错误的异常；不要处理愚蠢的异常，修复错误使其不会被抛出

• 安全错误：进入不安全模式

  try
  {
    result = CheckPassword();
    if (result == BadPassword) throw BadPasswordException();
  }
  catch(BadPasswordException ex) { ReportError(ex); return; }
  catch(Exception ex) { LogException(ex); }
  AccessUserData();
  

  看看发生了什么？我们未能进入不安全模式。如果 CheckPassword 抛出 NetworkDriverIsAllMessedUpException，那么我们会捕获它、记录它并访问用户的数据，而不管密码是否正确。无法进入安全模式；当你遇到任何异常时，假设最坏的情况。

• 安全错误：产生直接或间接泄露敏感信息的异常。

  这不完全是关于处理代码中的异常，而是关于产生由恶意代码处理的异常。

  有趣的故事。在 .NET 1.0 交付给客户之前，我们发现了一个错误，在该错误中可以调用引发异常的方法“调用此方法的程序集无权确定文件 C:\foo.txt 的名称”。伟大的。谢谢你让我知道。是什么阻止了所述程序集捕获异常并询问其消息以获取文件名？没有。我们在发货前解决了这个问题。

  这是一个直接的问题。一个间接的问题是我在LoadPicture 的VBScript 中实现的问题。根据不正确的参数是目录、不是图片的文件还是不存在的文件，它会给出不同的错误消息。这意味着您可以将其用作非常慢的磁盘浏览器！通过尝试一大堆不同的事情，您可以逐渐了解某人硬盘上的文件和目录。应该设计异常，以便如果它们由不可信的代码处理，该代码不会从他们为导致异常所做的任何事情中了解用户的私人信息。 （LoadPicture 现在提供的错误信息少了很多。）

• 安全和资源管理错误：不清理资源的处理程序是资源泄漏等待发生。恶意的部分信任代码可以将资源泄漏用作拒绝服务攻击，这些代码会故意造成异常产生情况。

• 鲁棒性错误：处理程序必须假定程序状态混乱，除非处理特定的外生异常。对于 finally 块尤其如此。当您处理意外的异常时，您的程序中完全有可能甚至很可能发生了严重的问题。您不知道您的任何子系统是否正常工作，如果它们正常工作，调用它们是否会使情况变得更好或更糟。如果可能，集中精力记录错误并保存用户数据，并尽可能干净地关闭。假设一切正常。

• 安全错误：需要撤消具有安全影响的临时全局状态突变 在任何可能具有恶意的代码可以运行之前。恶意代码可以运行 before finally 块运行！有关详细信息，请参阅我的文章：

http://blogs.msdn.com/ericlippert/archive/2004/09/01/224064.aspx

Answer 2

像这样重新抛出异常：

try 
{ 
   // some code here
}
catch(Exception ex)
{
   // logging, etc
   throw ex;
}

这会杀死堆栈跟踪，使可用性大大降低。正确的重新抛出方法是这样的：

try 
{ 
   // some code here
}
catch(Exception ex)
{
   // logging, etc
   throw;
}

Answer 3

在许多情况下您应该尝试捕获特定异常时捕获所有异常：

try {
  // Do something.
} catch (Exception exc) {
  // Do something.
}

而不是：

try {
  // Do something.
} catch (IOException exc) {
  // Do something.
}

应按从最具体到最不具体的顺序排列例外情况。

Answer 4

用无意义的消息重新抛出异常。

try
{
    ...
}
catch (Exception ex)
{
   throw new Exception("An error ocurred when saving database changes").
}

你不会相信我在生产环境中经常看到这样的代码。

Answer 5

没有人谈论看到像这样的空 catch 块......

 try{  
      //do something
    }
catch(SQLException sqex){  
        // do nothing  
    }

也永远不要使用异常处理来创建替代方法流...

 try{  
     //do something  

 }catch(SQLException sqex){  

     //do something else  
 }

Answer 6

不在IDisposable 对象上使用using：

File myFile = File.Open("some file");
callSomeMethodWhichThrowsException(myFile);
myFile.Close();

myFile 在调用 myFile 的终结器之前不会关闭（可能永远不会），因为在调用 myFile.Close() 之前引发了异常。

正确的做法是

using(File myFile = File.Open("some file"))
{
    callSomeMethodWhichThrowsException(myFile);
}

编译器会将其翻译成如下内容：

File myFile = File.Open("some file");
try
{
    callSomeMethodWhichThrowsException(myFile);
}
finally
{
    if(myFile != null)
        myFile.Dispose(); //Dispose() calls Close()
}

因此，即使遇到异常，文件也会关闭。

Answer 7

重新抛出捕获的异常时忘记设置内部异常

try
{
    ...
}
catch (IOException ioException)
{
    throw new AppSpecificException("It was not possible to save exportation file.")
    // instead of
    throw new AppSpecificException("It was not possible to save exportation file.", ioException);
}

当我发布此答案时，我忘记提及出于安全原因，我们应该始终考虑何时包含内部异常。正如Eric Lippert 在another answer for this topic 上指出的那样，一些异常可以提供有关服务器实现细节的敏感信息。因此，如果将处理异常的调用者不受信任，则包含内部异常信息不是一个好主意。

Answer 8

空接：

//What's the point?
catch()
{}

重新抛出：

//Exceptions are for *adding* detail up the stack
catch (Exception ex)
{throw ex;}

Answer 9

假设涵盖许多场景的异常是特定的。一个真实的场景是一个 Web 应用程序，其中异常处理始终假定所有错误都是会话超时，并将所有错误记录并报告为会话超时。

另一个例子：

try
{
     Insert(data);
}
catch (SqlException e)
{
   //oh this is a duplicate row, lets change to update
   Update(data);
}

Answer 10

记录 Exception.Message 而不是 Exception.ToString()

很多时候，我看到代码只记录异常消息，而它应该记录 ToString 方法的返回。 ToString 提供了比 Message 更多的异常信息。除了消息之外，它还包括内部异常和堆栈跟踪等信息。

Answer 11

试图捕获 OutOfMemoryException 或 StackOverflowException - 它们会导致运行时关闭，因此可以从同一进程中（甚至从整个 CLR 中捕获它们？）

OutOfMemoryException：当没有足够的内存继续执行程序时抛出的异常。

"从 .NET Framework 2.0 版本开始，StackOverflowException 对象无法被 try-catch 块捕获，相应的进程默认终止。因此，建议用户编写代码来检测和防止堆栈溢出。”

Answer 12

未能在 catch 处理程序中捕获可能的异常。这可能会导致错误的异常向上传播。

例如：

try
{
    DoImportantWork();
}
catch
{
    Cleanup();        
    throw;
}

如果Cleanup() 抛出异常会怎样？您不希望在此 catch 处理程序中看到指向 Cleanup() 方法的异常。您想要原始错误。您可以尝试记录清理错误，但即使是您的日志记录代码也需要异常处理以避免从中引发异常。

try
{
    DoImportantWork();
}
catch
{
    try
    {
        Cleanup();        
    }
    catch
    {
        // We did our best to clean up, and even that failed.
        // If you try to log this error, the logging may throw yet another Exception.
    }
    throw;
}

Answer 13

错误

try
{
   // Do something stupid
}
catch
{
   // ignore the resulting error because I'm lazy, and later spend
   // a week trying to figure out why my app is crashing all over
   // the place.
}

更好

try
{
    /// do something silly.
}
catch (InvalidOperationException ex)
{
    /// respond, or log it.
}
catch (Exception e)
{
    /// log it.
}

Answer 14

使用异常进行正常的流量控制。例外应该例外。如果这是一个好的/预期的操作，请使用返回值等。