Objective-C中NSError实例化内存分配失败的处理疑问

核心结论 #

日常开发中完全不需要过度担心[NSError errorWithDomain:domain code:code userInfo:@{NSLocalizedDescriptionKey : desc}]的内存分配失败问题，这种场景极端罕见，且Apple的运行时机制会在内存极度不足时直接触发OOM崩溃，而非让对象创建失败返回nil。

为什么不用过度担心？ #

• 当内存不足到连NSError这种轻量对象都无法创建时，程序的运行环境已经极度恶劣，系统会优先触发内存回收，甚至直接终止进程（OOM崩溃）。这种场景在普通APP开发中几乎碰不到。
• Apple提供的NSError类工厂方法（如errorWithDomain:），内部实现会在内存分配失败时直接引发崩溃，而非返回nil。也就是说，你不会得到一个nil的NSError，要么创建成功，要么程序直接崩溃。

极端场景下的兜底处理（仅作参考） #

如果开发的是对稳定性要求极高的系统级应用，一定要考虑这种边缘情况，可以尝试以下方式：

• 用C语言的日志函数直接写入日志文件，避免Objective-C对象的内存分配，比如调用fprintf写入本地日志，同时返回预先定义的整数错误码（类似C语言的错误处理方式）。
• 提前初始化一个静态的NSError实例作为兜底，比如：

  static NSError *kOutOfMemoryError = nil;
  + (void)initialize {
      if (self == [NSError class]) {
          kOutOfMemoryError = [[NSError alloc] initWithDomain:@"com.yourdomain.outofmemory" code:-1 userInfo:@{NSLocalizedDescriptionKey:@"内存不足，无法创建错误对象"}];
      }
  }
  

  当创建新NSError返回nil时，返回这个静态实例。但要注意，OOM时系统可能会回收静态内存，这种方式也并非绝对可靠。

总结 #

普通业务开发中，不需要为NSError的内存分配失败额外做处理，把精力放在正常业务逻辑的错误处理上即可。只有在极端场景下，才需要考虑轻量化的兜底方案，但此时程序的稳定性已经难以保障。

内容的提问来源于stack exchange，提问作者Yijue Xu