为什么不使用错误一词代替异常呢?[关闭]


18

如果我们将异常称为错误,那么为什么不首先将其称为错误而不是异常呢?

如果在代码中将其称为异常,则在发生时将其称为错误。那么,为什么不首先将其称为错误?

感谢您的任何回答或评论。


我希望我提到的技术细节有助于弄清异常与错误的区别。BTW大问题,+ 1
Jeremy Thompson


1
我实际上不知道您怎么能混淆它们,因为它们是完全不同的东西。异常是由代码处理的情况,表示某种错误。通常,模糊的错误,无法完全解释的错误等等。-错误:根据定义,错误本身不是由代码本身处理的。它们甚至都不是错误,它们表明缺乏逻辑,不应该这样做。
tvCa 2014年

1
@NiklasRtz:为什么会有巨额赏金?无论如何,都会有很多人回答。
ThePopMachine 2014年

@ThePopMachine因为我喜欢悬而未决的问题,其他人可能会觉得有趣。我要回答我的“热门”问题,并尽可能回答。好的和有趣的问题和答案对我有很大帮助。我还为该程序员准备了一个有关错误处理和错误代码的新问题。该问题不是特定的代码编写方式,而是如何以有限且希望标准化的方式处理错误,例如可以返回有限数量的Web应用的示例。错误代码,默认效果如何以及代码部分的命名。
尼克拉斯

Answers:


93

好吧,这很简单:并非所有异常都是错误(同样,并非所有错误都将自身表现为异常)。

作为一个不是bug的异常示例,如果您正在从USB驱动器中读取文件,并且有人将驱动器从插槽中拉出。这将引发一个异常(在大多数支持异常的语言中)。但这不是代码中的错误。

相反,错误可能表现为计算错误或类似错误。您仍然会得到答案,这不是正确的答案。

话虽这么说,一个异常一直到栈顶的异常可能一个错误。在上面的USB示例中,您应该能够捕获该异常,并向用户显示一个不错的错误,说“我们无法从文件中读取文件,因为该文件已不再连接。” 或者其他的东西。如果仅向他们显示IOException和一些时髦的错误代码,那就是一个错误。但是例外本身不是。


1
即使我看我是怎么做的,您也是正确的:如果某个方法无法获取最近的城市(洛杉矶)的名称,它会捕获异常并返回较大的行政区域(例如,加利福尼亚州)的名称,但由于该方法适用无论如何,没有一个封闭城市的地方并不是一个bug,这是一个例外。你同意吗?
尼克拉斯,

1
@尼克:是的,我同意这一点。
Dean Harding

1
出现IOException和错误代码并不总是错误。这是一种诊断。我经常对个人脚本这样做,因为失败意味着我只是输入了错误的参数。
Thomas Eding 2014年

23

简单明了,异常不是(总是)错误!

当某些异常情况发生时,将引发(或应为)异常。如果我的硬盘驱动器出现问题,并且无法写入文件,那不是错误。那是硬件的故障。

错误通常是由于不良编程造成的。如果应用程序由于编程错误而执行了某些意外操作,则表明该错误。


1
嘿,我们几乎在同一时间回答了问题,并且举了基本相同的示例:-)
Dean Harding

5
@DeanHarding伟大的思想家都这么认为,对吗?:D

1
我同意你的第一句话,但我必须不同意你的最后一句话。在第一台计算机的错误(虽然杜撰的),事实上,一只飞蛾被困的中继点之间。发生故障的硬盘有何不同?
Scott Whitlock,

1
@ScottWhitlock我猜“ bug”有多个定义。我一直以为它是由人为造成的错误:en.wikipedia.org/wiki/Software_bug

1
@ScottWhitlock:据说程序员会说“不是我的错,一定是错误”,这适得其反,因为“错误”意味着软件错误。今天,硬件故障不会被称为错误,尽管错误可能会导致硬件故障。
jmoreno 2014年

20

它们不是同一件事。

一个错误是一个软件的意外情况:该软件没有做什么是应该做的。错误可能存在于软件开发的各个级别,从普通的老式错字到逻辑错误,再到功能规格不足。

一个例外,通过对比,可以指程序的任一个不寻常的情况下,偏离正常操作,或者更具体地,涉及用于以信号和处理这样的条件语言构造。

发生异常的事实可能是错误的迹象,但通常不是。例如,应该从URL下载文档并在本地处理文档的应用程序在远程服务器关闭时可能会引发异常:该应用程序偏离了正常操作(无法下载和处理文档),但是正确处理异常并恢复,则没有错误。

相反,错误的存在并不一定表明它是一个例外。应用程序可能会默默地丢弃您输入的数据,而不是将其存储在数据库中。没有异常被抛出,但这仍然是一个错误。


+1用于定义您的条款。通常,人们应该更频繁地这样做!
yfeldblum 2012年

这绝对是最明确的答案。非常清晰简洁。做得好!
洛克

5

异常和错误根本不相关。当然,有时您会引发异常,这意味着存在错误。但这有时仅表示异常情况,这不一定是程序中的错误。尤其是在像Java这样的对异常满意的语言中,每个标准操作及其引导程序都会抛出大约五个不同的异常,例如,打开文件失败,读取文件失败等。


3

异常并不总是与错误相关。认为这可能会导致您所做的事情出错。

我想到的一个示例是InetAddress.getByName(),用于解析域名。如果发生某种情况,并且抛出UnknownHostException,实际上不是代码问题。


2

软件错误是用于描述计算机程序或系统中的错误,缺陷,错误,故障或错误的通用术语,该错误,缺陷,错误,故障或错误会导致产生错误或意外的结果,或导致其行为异常。甚至可能是标签上的拼写错误。

异常与错误不同。每种异常(访问冲突,堆栈溢出等)都可以作为“第一次机会”或“第二次机会”异常引发给调试器。根据定义,第一次机会异常是非致命的,除非没有使用错误处理程序正确处理它们,这时再次将它们作为第二次机会异常(仅调试器可以处理)引发。

如果没有调试器处理第二次机会异常,则该应用程序将关闭。


2

您可能会自己合法地引发异常,希望永远不要故意引入错误。


这读起来更像是评论,请参阅“ 如何回答
gnat 2014年

1
简洁并不意味着它不是突出两件事之间差异的答案。
艾伦B

1

所有例外都不是错误。所有错误是否都是例外可能是一个争论的话题。

我们可以说异常是不属于正常或预期应用程序流程的事件。这些事件可以独立于代码的编写方式,而错误本质上是错误代码(例如错误的计算)导致的。

这是一个示例,说明不处理异常可能是一个错误。

让我们假设有一个程序将一些数据写入外部存储设备。写入时,外部存储设备已拔出,崩溃或可能被损坏(无论出于何种原因)。现在这是一个例外情况,现在无论编程语言是否支持例外处理,如果程序由于此事件而崩溃或行为异常,这都是一个错误。(最终用户可能不知道发生了什么。这也是非常不愉快的) 。但是,如果程序优雅地中止了该过程,则通知用户(换句话说,要处理该异常),这显然不是错误。

尝试捕获机制编程语言本质上是一种工具,可简化我们处理意外事件的出路。


1

简介:异常是不良结果的证据,错误是不良结果的(部分)原因。问题(待解决)不是异常,而是导致异常的原因。

Resoning:错误是在产品的设计或实施中的缺陷(不限于软件)。例如,由于规格错误或简单的构建错误,未使用额定值适当的继电器(时间/灵敏度/可靠性/容量)。一个例外是预测一个真实的世界/运行时间偏差(我敢说“预期”?)的行为,例如,车辆的失控,而驾驶。

显然,错误可能导致异常,因为1)中的示例可能导致2)中的示例。但是,并非所有例外都是由错误引起的,例如,由于操作员中风而导致车辆失控。


0

由于这个问题已经悬而未决,请允许我提及我在2003年发表的CUJ文章“异常还是错误?”,它似乎恰好解决了OP的问题。

基本上,本文定义了术语“ bug”和“ exception”(给出示例),并提出了处理它们的策略。

本文建议不要“处理”错误,而应使用断言标记它们。相反,真正的异常需要通过代码进行处理(可能抛出/捕获异常)。

要点是,异常相比,错误需要与之完全相反的策略。

上述文章现在可以从Dr.Dobb's获得:http : //www.drdobbs.com/an-exception-or-a-bug/184401686

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.