一本面对编程中出现的“错误”的秘密书

介绍

本文是一篇关于解决与编程密不可分的“错误”的思考方法和调试方法的文章。
请注意，它基本上是一个通用表达式，不依赖于开发环境或语言。

要点总结

面对错误的最短路径是“立即确定错误的位置和原因，并采取适当的措施。”是。
如果您拥有解决错误所需的所有信息并知道该怎么做，那么剩下的就是去做。

另一方面

• 不知道哪里出错了
• 我不知道是什么导致了错误
• 我不知道如何响应错误

首先如果“做出假设并进行测试。”通过这样做，我们将确定错误发生的位置并调查错误原因。
这里的重点是

• 正常工作“这应该是○○”（前提条件）确认
• 反向“应该是○○”“也许○○”（假设）洗掉
• 否认“也许 XX”“这是错误的，因为我检查了○○”（验证方法）考虑到

是。

例子

如果你找不到解决方案

• 查看官方文档和FAQ
• 为遇到相同问题的人寻找解决方案
• 与人交谈
• 回顾目前已经建立的假设和验证结果是否有奇怪的地方（有可能因为认识上的差异而做出错误的判断）
• 返回起点

一边工作一边借用身边的力量。

细节

从这里，我们将更具体地解释如何调查和处理错误。

第 1 部分 粗略分类错误

错误的主要分类

编程中会出现三种主要类型的“错误”。

语法错误（语法错误）

• 未闭合的括号或引号
• 句子不以分号结尾

如当有部分偏离编程语言规范的写作风格时出错
语法错误也被称为
如果这个词出现在错误信息中
您应该首先检查任何不正确的语法。

编译错误

• 加载 DLL 失败
• 试图使用不存在的属性或方法

如编译时出错
*编译：将编程语言中的源代码转换为可执行文件的工作
对于 javascript 和 Python 等解释型语言，源代码是逐行读取和执行的。
不存在编译错误。

运行时错误

• 内存不足
• 试图将数字除以“0”

如程序执行过程中发生的错误
运行时错误也被称为
取决于编程语言例外转换成
我们准备了一种机制，允许开发人员对发生的错误采取某种措施。
实现了发生异常时采取什么样的响应异常处理叫。
（输出错误日志、输出警告信息等）

语法错误也是编译时错误，但在本文中与编译错误分开处理。

除此以外

• 总金额计算不正确
• 输出表单的布局未对齐

即使进程本身已正常完成，系统仍无法按预期工作的情况。
在本文中缺点叫。

如何检查错误

IDE（集成开发环境）或编辑器检测到许多语法错误并发出警报。
另外，对于需要编译的语言，语法和编译错误会在编译时被捕获。
错误内容应该出现在IDE、终端等，所以这是解决错误的一个很好的线索。
例如，如果编辑器发出像图像这样的错误消息
“8号线的红色波浪线没用。”
应该猜到了。

另一方面，运行时错误和缺陷直到流程执行后才会出现，因此我们将通过检查操作（测试）来发现它们。
通过添加将错误内容写入日志文件等的处理，可以在测试后进行检查。
另外，在IDE等中提供。调试执行功能如果您使用 ，您可以轻松检查发生的错误的内容。

我们将在本文中跳过测试。
换句话说，我们将讨论在执行操作检查（测试）后发现错误后如何响应。

参考图

本章小结

• 即使是错误也有粗略的分类
• 通常在程序执行之前检测到语法和编译错误（取决于语言规范）
• 应通过测试查找运行时错误和错误

第 2 部分 组织有关错误的信息

“在哪里”和“什么”发生了

你应该知道的关于错误的第一件事是

• 错误在哪里
• 您遇到了什么错误？

将是其中之一
警方不能仅仅通过报告事件发生就采取行动。
有必要了解事件的现场和内容，例如“涩谷八公门前发生抢夺事件”。

在错误信息的信息中，指定位置的参考是

• 发生错误的文件名和行号
• 发生错误的函数（方法）的名称

是。关于错误的内容

• 错误消息本身
• （针对运行时错误）异常类型（○○异常）
• 错误是什么（对象名、类名等）

我认为如果你发现它更容易弄清楚发生了什么

除了从错误信息中掌握错误的内容之外，
程序执行的环境，数据的状态，你在系统上执行了什么样的动作等等。
收集以后调查和响应错误可能需要的信息也是一个好主意。

本章小结

• 组织“哪里”“什么”“什么错误”
• 阅读错误消息是解决问题的第一步
• 即使错误信息是英文，也不要转身养成翻译或查找的习惯

第 3 部分检查导致错误的位置

错误的可能原因有很多

如果在发生错误的地方存在实施问题，并且通过修复该错误解决了该错误，则没有问题。
但是，当被问及“发生错误的位置”=“导致错误的位置”时，情况并非如此。
原因也很有可能是在导致错误的处理之前的处理中存在问题。
例如，假设有如下过程，将两个字符串转换为整数值，求相加值。

在执行这个过程时，在第三个过程“将变量A和B转换为整数值并将相加的值存储在变量C中”出现错误。
它说“无法转换为数字”。
原因是什么？

列出可能性
・错误使用函数转换为整数值，将不适当的值传递给参数
・“将变量 A 和变量 B 转换为整数值”应该是“将变量 A 和变量 C 转换为整数值”。
③的处理有可能出现问题，例如

・本来打算读aaa.txt，但是读了ccc.txt
・不是将 aaa.txt 的内容存储在变量 A 中，而是将内容存储在变量 B 中
上一个过程中出现错误的模式，例如
・首先，aaa.txt 或 bbb.txt 文件的内容不是数字
也有可能原因在程序以外的地方。

那么，在所有这些可能性中，您从哪里开始寻找真正的原因呢？
关键词是“假设”和“分离”。

步骤 1 组织流程

首先，一个程序由几个进程组成。
并且处理主要基于“前提”。
为了使上述过程成功，

• 在①的过程中，您应该能够成功读取文件 aaa.txt。在文本文件中由于应该只有一个数字值，它作为字符串的值它应该存储在变量 A 中。
• ②加工与①的处理几乎相同因此，文件名应该是 bbb.txt 并存储在变量 B 中。
• 作为处理①和②的结果，变量 A 和变量 B 应包含字符串数字是。为了作为数字进行加法运算，首先需要将这些字符串转换为数字类型。要进行转换，请使用作为标准函数提供的 toNumber 函数（临时）。这个 toNumber 函数只有一个参数，如果你传递字符串的数字，数字将作为返回值返回。这就是为什么如果将数字相加并将结果存储在变量 C 中，您应该能够达到所需的要求。是

它是设计好的。
相反，可以说这个逻辑崩溃了，并且由于其中至少一个的偏差而发生了错误。

步骤 2 列举错误原因的可能性（假设）

在步骤1中，收集了理想状态，因此在此基础上，列举了错误的可能原因。

Step 3 先检查容易确认的可能性

例如，“我应该把它放在变量 A 中，但它放在变量 B 中”
如果是这样的关卡，只要快速查看源代码就可以注意到它。
最好先看看这些东西。
如何在遵循源代码的同时发现错误桌面调试叫。

Step 4 总结切割方法

程序中的行数越多，可能性范围越广，检查就越简单。
时间不多了。
为了有效地消除步骤 2 中列出的许多可能性，重要的是在分离它们之后确定调查的顺序。

分治法有一种方法。它旨在通过将大问题分解为较小的问题来确定原因。
在这种情况下，最大的问题是“无法将从文件中读取的数字字符串转换为数字”变成。
广泛地打破这一点
“我在从文件中获取数字时遇到问题”
或者“字符串转数字过程中出现问题”变成。
例如，如果从处理(1)和(2)的文件中获取字符串的数值的处理成功。
变量 A 应包含 aaa.txt 中的数字，变量 B 应包含 bbb.txt 中的数字作为字符串。
如果能确认，就可以判断“从文件中获取数值”的过程没有问题。
在第 5 步的调查中，当过程进行时，考虑检查什么来隔离上述问题。

步骤 5 开始调查

嵌入调试日志以进行调查是很常见的。
另外，在IDE等中提供。调试功能如果您使用 ，您可以轻松检查发生的错误的内容。
在调试功能中

• 断点（允许您在指定行临时停止处理）
• 步骤执行功能（您可以按自己的时间对每个步骤进行处理）
• 处理过程中浏览变量中的值

它对进行研究非常有帮助，因为它具有以下功能

作为调查原因的结果，您可能最终会陷入迷宫。
如果你怎么找都找不到原因
・检查在当前环境下是否可以重现此问题。 （在被调查环境中正常工作的可能性）
・与不同的人共享信息，而不是单独遇到问题
・通过向其他人解释您到目前为止所调查的内容，您可以期望提出“尚未尝试的解决方案”、“新想法”和“进一步的问题”（橡皮鸭调试） .
・休息一下，重新调整心态。
・如果过于深入研究原因，到达疯狂的部分，请寻找没有检查过的基本部分。
等等。

本章小结

• 由于错误原因多种多样，首先列出可能的可能性作为假设
• 用桌面调试看源码找到可以理解的原因
• 采用分而治之的方法，大范围划分和调查问题，缩小范围，然后调查细节

Part 4 考虑如何应对错误

一旦确定了错误的原因，我们将开始考虑如何处理它。
我将省略细节，但最好从以下角度考虑如何处理发生的错误。

响应时的影响程度如何

如果是本地没有问题，但如果是跨多个功能，则修正和操作确认的工时会增加。
在期限和预算固定的系统开发中，所需的工时数是重要因素之一，因此有必要调查影响的程度。
（首先，在防止与工时无关的多功能问题方面也很重要。）

预期错误或意外错误

预期错误是指即使在正常操作期间也可能在某些情况下发生的错误。
比如，我们在注册10万条数据的过程中，有一个过程，由于输入不足，不可避免地会出现错误。
不要为了一个而取消所有 100,000 个注册，而应避免只注册导致此错误的那个，等等。
如果您甚至可以假设会发生错误，则可以考虑各种措施。

意外错误是在正常操作中不会发生的错误，无法对意外错误采取灵活的措施。
因为比较困难，所以基本上经常通过中断进程来处理错误。

有什么我可以做或应该放弃的吗？

例如，当使用外部提供的 API 或库时，
错误可能发生在我们无法控制的领域。
如果您可以在确定的规格范围内对错误采取措施，那很好，但如果错误不可避免地发生
比如从原来的构建中回顾，把程序本身当成运行中的错误来吸收。
如何应对也将是一个候选。

本章小结

• 首先调查一下如果用简单的方法响应错误会有多大的影响
• 错误有时是一个问题，程序更正以外的解决方案也是候选解决方案。
• 即使出现意外错误，也最好处理错误。

概括

即使您以前从未见过错误，原因可能非常简单，因此首先冷静下来并理清发生了什么很重要。
之后，如果您能参考这里描述的调试方法并尽可能多地消除错误，我将不胜感激。

Bonus 1 关于经验

当然，您发展的年限越长，您获得的经验就越多。
积累的知识可以起到积极的作用，但也可以起到消极的作用。
可能性的数量随着过去记忆的触发而膨胀，“说起来，这种事情发生在很久以前。”
我个人认为，在完成一定的研究之后再去寻找旧抽屉比较好，因为你膨胀得越多，就越难把你的研究放在首位。
当然，你拥有的经验越多，你的假设和优先级就越准确，你的调试技能也会越好，所以经验并不意味着不好。

奖励 2 如果您被其他人咨询

如上所述，重要的是要获得其他人的见解以解决错误。
有些人可能认为，在获取知识方面，有必要给咨询的人提供以前从未存在过的新知识。
我认为，被咨询的人的角色不存在，而是从第三方的角度去开拓。

首先，询问有关情况的详细问题并澄清您检查的内容。
在这个澄清阶段咨询的人有很多模式可以自我解决。
听到一定程度后，根据获得的信息考虑尚未确认的部分
我认为对被咨询方提出下一步行动的建议是对被咨询方最好的回应。

原创声明：本文系作者授权爱码网发表，未经许可，不得转载;

原文地址：https://www.likecs.com/show-308626078.html