Question

显然，这是一种很好的做法。那不用说了。我每次都会在示例代码中看到它（例如socket()，fork()或malloc()，仅举几例）。我知道这样做，我只是不明白为什么这么多。他们经常容易失败吗？是因为系统调用是在内核模式下进行的吗？背后的原因是什么？

Answer 1

我认为你在问为什么调用这些例程的代码会检查结果以确定是否发生了错误。

您引用的每个例程socket，fork和malloc都需要资源。这些资源可能不可用，因为调用进程已超出系统管理员或用户设置的限制，或者因为系统已耗尽其拥有的资源而无法再向进程提供。因此，即使不经常，也可能对这些例程之一的调用将返回失败。因此调用过程应检查失败。

另外，在一些实现中，如果在操作完成之前将信号传递给过程，则可以中断一些系统例程（诸如read和write）。（当信号到达时，它被认为是重要的，并且希望立即将其传递给过程而不是等待可能长的操作完成。因此操作被中断，信号被传递，过程可以处理信号然后从控制器返回到调用原始例程的代码，并且必须通知该代码操作被中断。）这种中断导致返回失败并返回错误状态，指示操作被中断。 / p>

Answer 2

总是，如果只是.. 回想当C函数只返回一个整数，异常是科幻小说时，他们提出了返回成功的代码或者提供关于出错的线索的代码。它成了一个惯例。

取决于你所谓的失败。

打开文件（鉴于开发人员可能会受到打扰）之类的东西相对容易处理，例如找不到文件。 Malloc，采取一些补救措施有点困难。

关键是尽可能检查错误附近。如果不这样做，当您尝试将大量计算的结果写入其中并获得访问冲突时，您会发现要打开和追加的文件以后不存在10,000行代码。

基本上这个东西是发明例外的原因。检查返回值是“可选的”，吞下异常是明确的。

Answer 3

示例：

FILE *fp;

fp = fopen("c:\\removedDirectory\nonexistingFile.txt", "r")//returns NULL  

if(fp != NULL)
{
    //stuff here will fail if fp == NULL

}

如果你不检查fopen的输出，（替换为任何返回错误的函数）和fp为NULL，后续函数取决于真实的文件流将不起作用

为什么C中的系统调用总是被错误检查？

3 个答案: