很容易假设一个系统在现场表现得和在工程台上一样完美。在开发过程中，嵌入式软件是在最好的条件下编写的。嵌入式开发人员知道，或者至少有他们自己的系统应该如何工作的概念。 事情通常运行得相当顺利，但随着成千上万的设备开始进入用户手中，意外发生和错误发生的可能性在统计上变得很可能。在今天的文章中，让我们探讨开发人员编写可以处理意外错误的软件所需的策略。

　　策略 #1 – 不断考虑可能出现的问题

　　开发人员需要部署以处理错误的第一个策略是在编写每一行代码时积极质疑可能出现的问题。例如，当我为如下函数编写实现时：

　　void Dio_WriteChannel(DioChannel_t Channel, bool state)

　　{

　　// Additional code goes here

　　}

　　我问自己几个问题：

　　如果 Channel 参数超出范围会发生什么?

　　该函数应该返回错误代码还是成功标志?

　　如何验证所需的通道状态是否已更改?

　　如果状态试图改变但不能改变，我该怎么办?

　　内存是否会损坏，以至于我的bool状态变量不是真假? 如果是这样，我该如何处理?

　　断言是否足以在开发时检查边界条件，还是应该对参数进行实时检查?

　　这是很多问题，或者诸如简单通用代码块之类的问题，我们真的还没有开始填写细节!但是，如果你希望能够处理错误，则必须不断地质疑代码以及可能出现的问题。

　　策略 #2 – 使用 TODO 记录疑虑和问题

　　随着软件的开发，有时问题多于目前的答案。在上面的示例中，可能还没有关于如何处理返回错误的答案。暂时就这样真的很容易，但是随着其他问题会出现，这个问题就会被遗忘在喧嚣中。

　　大多数现代 IDE 都会有自定义标签，可以从代码中提取这些标签来创建一个列表，例如使用 TODO。这些将显示为信息性消息。如果有需要处理的错误，但我不知道如何处理，我会使用 TODO。如果有一个实现，但我想查看它，我可能会使用 TODO，但也可能使用其他一些我可以轻松搜索代码的关键字。需要注意不要让 TODO 信息消息过载，否则它会变得太嘈杂，但我们也希望确保我们不会丢失我们的问题或问题。 (是的，可以使用外部跟踪器，但我发现将其与代码一起保存要容易得多，因此代码审查员和其他嵌入式开发人员可以轻松地看到它)。

　　策略#3 – 总是抱着“以后会改的态度”

　　现在是修复、记录或实施错误检查的最佳时机。总是有某些问题正在引起开发人员的注意，虽然我们总是想返回并添加错误处理，但却总是在拖延!

　　一旦某些事情似乎对管理层有用，就该着手处理下一个紧迫问题了。如果它有效，你为什么要在它上面投入更多的时间来减少回报?管理层没有意识到你没有包括错误检查或实施中存在巨大的漏洞!如果产品需要健壮性，请不要尝试稍后添加它，或者相信你可以稍后再返回并修复它。

　　结论

　　嵌入式开发人员编写软件的方式决定了他们的系统是否能够从错误中优雅地恢复，关键是要有正确的开发态度，在编写软件时考虑可能出现的问题并实施恢复机制。为了更好地处理错误，请处理当前可能出现的问题，否则将永远无法处理。