如果我们将异常称为错误,那么为什么不首先将其称为错误而不是异常呢?
如果在代码中将其称为异常,则在发生时将其称为错误。那么,为什么不首先将其称为错误?
感谢您的任何回答或评论。
如果我们将异常称为错误,那么为什么不首先将其称为错误而不是异常呢?
如果在代码中将其称为异常,则在发生时将其称为错误。那么,为什么不首先将其称为错误?
感谢您的任何回答或评论。
Answers:
好吧,这很简单:并非所有异常都是错误(同样,并非所有错误都将自身表现为异常)。
作为一个不是bug的异常示例,如果您正在从USB驱动器中读取文件,并且有人将驱动器从插槽中拉出。这将引发一个异常(在大多数支持异常的语言中)。但这不是代码中的错误。
相反,错误可能表现为计算错误或类似错误。您仍然会得到答案,这不是正确的答案。
话虽这么说,一个异常一直到栈顶的异常可能是一个错误。在上面的USB示例中,您应该能够捕获该异常,并向用户显示一个不错的错误,说“我们无法从文件中读取文件,因为该文件已不再连接。” 或者其他的东西。如果仅向他们显示IOException
和一些时髦的错误代码,那就是一个错误。但是例外本身不是。
简单明了,异常不是(总是)错误!
当某些异常情况发生时,将引发(或应为)异常。如果我的硬盘驱动器出现问题,并且无法写入文件,那不是错误。那是硬件的故障。
错误通常是由于不良编程造成的。如果应用程序由于编程错误而执行了某些意外操作,则表明该错误。
它们不是同一件事。
一个错误是一个软件的意外情况:该软件没有做什么是应该做的。错误可能存在于软件开发的各个级别,从普通的老式错字到逻辑错误,再到功能规格不足。
一个例外,通过对比,可以指程序的任一个不寻常的情况下,偏离正常操作,或者更具体地,涉及用于以信号和处理这样的条件语言构造。
发生异常的事实可能是错误的迹象,但通常不是。例如,应该从URL下载文档并在本地处理文档的应用程序在远程服务器关闭时可能会引发异常:该应用程序偏离了正常操作(无法下载和处理文档),但是正确处理异常并恢复,则没有错误。
相反,错误的存在并不一定表明它是一个例外。应用程序可能会默默地丢弃您输入的数据,而不是将其存储在数据库中。没有异常被抛出,但这仍然是一个错误。
所有例外都不是错误。所有错误是否都是例外可能是一个争论的话题。
我们可以说异常是不属于正常或预期应用程序流程的事件。这些事件可以独立于代码的编写方式,而错误本质上是错误代码(例如错误的计算)导致的。
这是一个示例,说明不处理异常可能是一个错误。
让我们假设有一个程序将一些数据写入外部存储设备。写入时,外部存储设备已拔出,崩溃或可能被损坏(无论出于何种原因)。现在这是一个例外情况,现在无论编程语言是否支持例外处理,如果程序由于此事件而崩溃或行为异常,这都是一个错误。(最终用户可能不知道发生了什么。这也是非常不愉快的) 。但是,如果程序优雅地中止了该过程,则通知用户(换句话说,要处理该异常),这显然不是错误。
尝试捕获机制编程语言本质上是一种工具,可简化我们处理意外事件的出路。
由于这个问题已经悬而未决,请允许我提及我在2003年发表的CUJ文章“异常还是错误?”,它似乎恰好解决了OP的问题。
基本上,本文定义了术语“ bug”和“ exception”(给出示例),并提出了处理它们的策略。
本文建议不要“处理”错误,而应使用断言标记它们。相反,真正的异常需要通过代码进行处理(可能抛出/捕获异常)。
要点是,与异常相比,错误需要与之完全相反的策略。
上述文章现在可以从Dr.Dobb's获得:http : //www.drdobbs.com/an-exception-or-a-bug/184401686