【问题标题】:What is the difference between an error and an exception in .NET?.NET 中的错误和异常有什么区别?
【发布时间】:2011-01-26 23:14:43
【问题描述】:

能否请您解释一下错误和异常之间的区别是什么?

【问题讨论】:

  • +1 有趣的问题,我从来没有想过。
  • 您可能想澄清“错误”的含义,因为该术语在广泛的上下文中使用,即使在 .NET 世界中也是如此。甚至“异常”在 Win32 结构化异常处理(这是一种用于报告错误的 Windows 操作系统机制)和托管 System.Exception(这是一种用于报告错误的 CLR 机制)之间也可能是模棱两可的。
  • 相关(Java 特定):stackoverflow.com/questions/912334/…
  • +1 给 Frank 以提高透明度。

标签: c# .net exception


【解决方案1】:

异常是利用语言语义的类。正如其他人所说,异常会中断堆栈的执行,直到被捕获。异常可以用于传达错误,但更一般地用于传达发生了异常情况。

另一方面,错误可能是异常的,也可能不是。

有几种错误:

  • 用户错误 - 应该毫无例外地处理此问题
  • 语法错误 - 这不应该在静态类型语言中编译(在动态语言中,它们更难发现)
  • 运行时错误 - 这将导致异常或静默失败(通常会产生意外结果)

确实,异常应该仅限于处理运行时错误,因为用户输入错误数据并不是“异常”。要处理用户错误,您应该采取以下方法:

  • 防止输入错误数据(前端验证)
  • 防止不良数据被持久化(后端验证)

应将异常用作用户错误的“最后一道防线”。如果您正在编写持久层,则可以依靠异常来确保通过验证的不良数据不会被持久化。但是,您应该通过在验证中首先防止错误发生来修复其中任何一个问题。

【讨论】:

  • 我认为用户错误可能会在内部处理异常(例如,返回自定义异常的验证方法)。不过,这些异常将被捕获并以友好的方式报告。这不是正常的控制流程,也不会影响性能。
  • @TrueWill - 我同意。我曾经需要使用异常捕获/重新抛出作为流控制“范式”。这是一个异国情调的案例,但我很高兴有一些东西可以让我完成我需要做的事情......@Michael,没有反对意见,但我也不完全同意。
  • 我想我说得不够好。异常不应该是确保正确输入的主要机制。如果不良数据通过验证,则成为例外情况。这就是我所说的“异常可以用来传达错误”的意思。我将“can”斜体。
  • @TrueWill - 我希望可以否决评论。 ;) 用户错误不应与异常一起处理,因为用户错误不是异常情况。用户错误总是发生。想想必须验证的文本框中的不正确输入。异常对性能有很大影响,不应用于处理应属于您的设计和要求的条件。
  • @Nick @TrueWill 我认为你们都是对的。在用户输入错误数据的情况下,这不是异常,但是如果程序员让它进入持久层,那么它确实会变得异常。在保存坏数据时,代码不知道如何响应某些数据不应该保存的事实,因此创建了一个例外情况。 edit 将“than”更改为“then”。我讨厌把它们混在一起。
【解决方案2】:

异常是派生自System.Exception 类的类型的对象。在 throw 语句中使用它来将控制权转移到位于调用堆栈上方的 try 块中的 catch 子句。

错误只是您要解释的一些代码或消息。错误代码的问题在于您可以决定忽略它们:

MethodThatReturnsAnError();
SomeCodeThatShouldNotExecuteOnError();

如果返回错误代码,该调用将简单地忽略错误代码。然而:

MethodThatThrowsAnException();
SomeCodeThatShouldNotExecuteOnError();

这不能被忽略,并且会将控制权转移到堆栈上,超过“SomeCodeThatShouldNotExecuteOnError();”。

【讨论】:

  • 我不知道我是否会说错误代码有问题,而是说,除了异常,您可以利用“某人”必须处理异常而错误可能是这样的事实无视。异常并不比错误好。他们就是所谓的例外。发生了异常情况,正在中断流程。
  • @LucasB:错误代码可以忽略的事实是错误代码的问题。再加上它们在语义上是轻量级的。
  • 从语义上讲,异常不一定是错误,它只是应该中断“正常”代码路径以支持“异常”代码路径。大多数情况下,这与“错误”的含义相同,但随后我们可以就“错误”的含义展开语义辩论。 “系统错误”、“程序员错误”和“用户错误”在概念上都是“错误”,但在用户界面代码中,“用户错误”(例如在文本框中输入无效值)通常不会被视为“异常”,足以抛出异常。
  • 我可能会澄清您可以决定无意忽略错误代码。您仍然可以通过在 catch 块中使用不执行任何操作的 try/catch 来忽略异常。
  • @CrimsonX:完全正确。通过使用人眼或工具查看代码,您忽略了异常这一事实是显而易见的。
【解决方案3】:

您必须编写代码忽略的异常。错误代码你必须写代码来不忽略。

【讨论】:

  • 我喜欢这个,所以我投了赞成票。但是,您必须已经了解异常和错误(如您所说,错误代码),才能吸引它。所以简洁的最高分,但我不确定它是否真的回答了这个问题:)
【解决方案4】:

通常,我将它们分类为:

错误 - 是应用程序中已知的工作流程。例如:身份验证期间未提供用户名是一个错误。
应用程序可以处理这些情况并能够向用户显示友好的消息,以提示正确输入和/或以不同的方式处理数据。

Exception - 通常在系统退出和/或应用程序中发生意外情况时抛出。例如:打开文件句柄可能会因权限不足或文件不存在而引发异常。
通常在这种情况下,应用程序可以捕获这些异常和/或编写通用处理程序来处理系统中的所有异常。

根据经验,如果您知道存在导致应用程序无法继续工作的特定案例,请将其标记为错误并妥善处理该案例。

所有剩余的“未知-未知”都可以归入例外类别。

HTH。

【讨论】:

    【解决方案5】:

    如果不存在给定异常的异常处理程序,程序将停止执行并显示错误消息。

    未处理的异常是错误。所以所有错误都是例外,但反之则不然。 异常处理技术处理异常/意外情况(错误),虽然错误是我们没有预料到会发生的情况,但我们必须通过将用户重定向到某个静态 HTML 页面并将其捕获到日志中来处理它们为发生的错误提出解决方案。

    错误可能发生在 2 个级别

    • 页面级别(在页面指令中使用 ErrorPage 属性)
    • 应用级别(需要在 web.config 中处理)

    编译 自定义错误...自定义错误 错误....错误 汇编 注意 - 页面级错误处理会覆盖应用程序级错误处理。

    异常处理:->

    【讨论】:

      【解决方案6】:

      异常是报告和处理执行失败的一种方式。换句话说,它们用于传达错误条件(在 Framework Design Guidelines 书中解释 Krzysztof Cwalina)。

      【讨论】:

        【解决方案7】:

        异常:当某个操作中的某个步骤失败时,该操作中的所有后续步骤都不会执行。这就是例外的亮点。

        错误: 就像在第一种情况下,您想暂停当前代码的执行,但在此之前您需要释放之前分配的任何资源。


        话虽如此,

        异常类有HResult property。 HRESULT 是一个 32 位的值,分为三个不同的字段:严重性代码、设施代码和错误代码。

        看看这篇文章,会帮助你更好地理解

        【讨论】:

          【解决方案8】:

          错误是事件。异常类表示在应用程序执行(运行时)期间发生的错误,并提供了一种使用 try catch 块来处理它们的机制。 错误可能是运行时或编译器错误。

          错误事件示例: System.Web dll的HttpApplication.Error事件,System.IO的FileSystemWatcher.Error事件 两个 dll 都有相同的错误事件定义

          public event EventHandler Error
          

          来自 .Net Framework 4.5 文档https://msdn.microsoft.com/en-us/library/system.exception(v=vs.110).aspx

          异常类表示应用程序执行期间发生的错误。

          错误和异常

          运行时错误可能因多种原因而发生。但是,并非所有错误都应作为代码中的异常处理。以下是运行时可能发生的一些错误类别以及相应的响应方式。

          使用错误。使用错误表示程序逻辑中可能导致异常的错误。但是,错误不应该通过异常处理来解决,而是通过修改错误代码来解决。

          程序错误。程序错误是无法通过编写无错误代码来避免的运行时错误。

          在某些情况下,程序错误可能反映了预期的或例行的错误情况。在这种情况下,您可能希望避免使用异常处理来处理程序错误,而是重试操作。

          在其他情况下,程序错误反映了可以在您的代码中处理的意外错误情况。

          系统故障。系统故障是无法以有意义的方式以编程方式处理的运行时错误。例如,如果公共语言运行时无法分配额外的内存,任何方法都可能引发 OutOfMemoryException 异常。通常,系统故障不是通过使用异常处理来处理的。相反,您可以使用诸如 AppDomain.UnhandledException 之类的事件并调用 Environment.FailFast 方法来记录异常信息并在应用程序终止之前通知用户失败。

          【讨论】:

            猜你喜欢
            • 2022-07-15
            • 2013-04-15
            • 2011-08-14
            • 2018-09-15
            • 2011-02-24
            • 2019-11-26
            • 2020-12-20
            • 2020-05-20
            • 2011-02-13
            相关资源
            最近更新 更多