C语言不像Java或Python那样有异常机制，函数执行失败时往往只能通过返回值通知调用者。返回值错误并不等于程序崩溃，它更像是一个状态信号，但这个信号能不能被正确理解，取决于你是否了解函数的契约：返回什么代表成功、返回什么代表失败、失败后还有哪些辅助信息可查。比如fopen返回FILE *，失败时返回NULL，而read返回ssize_t，失败时返回-1，两者在类型和错误判断上完全不同。如果只记住某一类规则，就可能在遇到不同函数时误判返回值，甚至把失败当成正常数据继续处理。
因此处理返回值错误的第一件事，不是急着写if，而是搞清楚当前函数属于哪一种返回值约定。C标准库内部的约定并不统一，有的函数用指针表示资源，有的用整数表示状态，还有的用char *返回字符串结果。忽略这些差异，后面所有错误判断都可能建立在错误前提上。下面从几个层次拆解这个问题。
先分清返回值类型与错误语义
指针类函数的错误判断相对直观。像malloc、fopen、opendir这些函数，成功时返回有效地址，失败时返回NULL。但这里有一个容易忽略的细节：malloc(0)可能返回NULL或一个可free的指针，具体行为由实现决定。也就是说，返回NULL并不总是代表内存不足，还可能是因为你请求了零字节内存。因此只判断NULL还不够，最好结合输入参数和上下文确认是否真的失败了。
整数类函数的规则更加多样。read、write、open等系统调用返回-1表示出错，但标准I/O函数如printf返回负数表示出错，puts则返回EOF。还有一些函数把返回值和业务结果混在一起，比如getchar成功时返回读取到的字符，失败或到达末尾时返回EOF。这就带来一个典型问题：如果文件内容里本身包含与EOF等价的字节，调用者需要结合feof和ferror才能区分真正状态。理解这些差异后，再遇到返回值错误时，就能先判断它是状态码、资源指针还是业务数据。
配合errno定位具体原因
很多C标准库函数在返回错误时，还会设置全局变量errno来补充错误原因。例如fopen返回NULL，但具体是文件不存在、权限不足还是路径过长，可以通过errno的值进一步判断。调用strerror(errno)可以把错误码转换成可读字符串，调用perror则可以直接把前置错误信息输出到标准错误流。下面是一个完整的打开文件与错误处理示例。
#include <stdio.h>
#include <errno.h>
#include <string.h>
int main(void)
{
FILE *fp = fopen("data.txt", "r");
if (fp == NULL) {
fprintf(stderr, "打开文件失败: %s\n", strerror(errno));
return 1;
}
/* 这里执行读取逻辑 */
if (fclose(fp) != 0) {
fprintf(stderr, "关闭文件失败: %s\n", strerror(errno));
return 1;
}
return 0;
}
这段代码里，fopen返回NULL后没有直接写打开失败这种模糊提示，而是通过strerror(errno)输出系统给出的具体原因。需要特别注意的是，errno只在函数调用失败后才有效，成功时它的值可能被保留或清零，因此不要因为errno非零就判断出错。正确做法是先检查返回值，确定失败后再读取errno。另外，某些函数即使成功也不保证errno保持不变，所以任何基于errno的判断都必须紧跟失败点。
在多线程程序中，errno通常被实现为线程局部变量，每个线程有独立副本，这在宏观上解决了不同线程互相干扰的问题。但如果在失败后没有立刻保存errno，而是继续调用printf、malloc等可能修改errno的函数，再想输出原始错误码就可能拿到错误值。因此更稳妥的做法是先把errno存入局部变量，再做日志或清理操作。
避免三类常见返回值错误
第一类是完全忽略返回值。像printf、fclose、scanf这些函数，实际项目中很多调用者默认它们总会成功，但从健壮性角度看，输出重定向到失败磁盘、文件系统已满、输入格式不匹配时，这些函数同样会返回错误。忽略fclose的返回值尤其危险：写入缓冲区可能在fclose时才真正刷到磁盘，如果这时候返回错误，之前所有写入都可能丢失。正确的做法是检查这些看似无害的函数返回值，并给出相应处理。
第二类是把业务数据与错误码混用。比如设计一个函数find_index，返回元素下标，失败时返回-1。但如果元素确实存在且下标就是-1，这种设计就产生了歧义。更合理的做法是使用指针参数输出结果，函数返回专门的错误码，或者定义一个结构体同时携带状态和数据。这样调用者不需要猜测返回值到底表示业务成功还是运行失败。
第三类是只检查了返回值，却没有结合上下文判断。例如recv函数在网络编程中返回0表示对端关闭连接，返回-1表示真正出错，返回正数表示收到字节数。如果调用者统一把小于等于0当成连接断开，就会把-1错误地当作正常关闭处理，漏掉潜在的网络故障。类似地，read返回0通常表示到达文件末尾，但-1可能是被信号中断，需要结合errno == EINTR决定是否重试。
设计一套清晰的返回值检查流程
对于个人项目或小型模块，可以统一采用0表示成功、非0表示失败的约定。这样所有函数返回int，调用方只需要判断if (ret != 0)。但当函数需要返回更多信息时，建议使用输出参数传递业务结果，返回值只用来表示状态。下面是一个统一错误码的示例。
#include <stdio.h>
typedef enum {
ERR_OK = 0,
ERR_NULL_POINTER,
ERR_OUT_OF_RANGE,
ERR_RESOURCE_NOT_FOUND,
ERR_UNKNOWN
} err_t;
err_t get_item_by_id(int id, int *out_value)
{
if (out_value == NULL) {
return ERR_NULL_POINTER;
}
if (id < 0 || id > 99) {
return ERR_OUT_OF_RANGE;
}
/* 模拟查找逻辑 */
if (id == 50) {
return ERR_RESOURCE_NOT_FOUND;
}
*out_value = id * 10;
return ERR_OK;
}
int main(void)
{
int value = 0;
err_t ret = get_item_by_id(42, &value);
if (ret != ERR_OK) {
fprintf(stderr, "获取数据失败，错误码: %d\n", ret);
return 1;
}
printf("value = %d\n", value);
return 0;
}
这种设计让返回值的语义非常明确：只要不是ERR_OK，就说明函数没有完成预期工作。业务数据通过out_value携带，不会和错误状态挤在同一个返回值里。对于更复杂的场景，还可以把错误码做成独立的头文件，配合switch或映射表把错误码转换成可读信息。这样排查问题时不必反复查文档，也能保证团队内部代码风格一致。
如果函数涉及多个资源申请和释放，建议使用goto做统一清理。每步操作先检查返回值，一旦失败就跳转到相应的清理标签。这样既可以避免重复写释放逻辑，也能防止因为提前return导致文件句柄或内存泄漏。虽然goto在部分教材中被认为不够优雅，但在错误处理场景下，它是C语言中保持清晰和简洁的有效工具。
从现象到定位：实际排查步骤
当你怀疑某个返回值错误导致了逻辑异常，第一步是确认函数的返回值类型和成功/失败约定。可以查看手册或头文件，把返回值的所有可能取值列出来。第二步是在失败分支中打印或记录返回值、errno以及相关输入参数。注意日志要包含足够上下文，比如文件名、缓冲区大小、循环次数，否则只看到-1很难定位问题。
第三步是构造最小复现用例。把出错的函数调用抽出来，固定输入参数，观察是否稳定返回错误。如果问题只在特定数据下出现，就需要进一步结合调试器在失败分支设置断点，查看栈帧和变量。对于系统调用相关错误，还可以用strace观察内核返回的具体错误码，这比单纯读代码更快定位原因。整个过程中，不要一看到返回值错误就修改调用方式，要先确认是函数用法错误、输入数据非法，还是底层资源状态异常。
最后，在修复错误后补充边界测试。比如用空指针、超大缓冲区、特殊字符路径、只读文件系统等情况验证函数返回值处理是否正确。只有把返回值检查纳入测试用例，才能避免同类问题在后续修改中再次出现。C语言的返回值机制虽然简单，但真正用好它需要结合类型语义、errno、错误码设计和清理流程，形成一个完整的处理闭环。