objective-c中的返回错误

我刚接触objective-c，我开始想知道处理和捕捉错误的常用/标准/正确方法是什么

---

似乎可以使用NSError来实现这一点，这是一个好主意还是劫持了cocoa？

我很确定NSError类就是这么做的-提供有关错误的详细信息。您将看到的最常见模式是一个方法，该方法使用指向NSError对象的指针，如中所示：

- (id)doSomethingWithArgument:(id)arg error:(NSError **)error

该方法为执行某项操作的结果返回一些值（或者可能是

nil

），但如果调用失败，将在传递的指针处放置一个NSError对象，其中包含有关失败的详细信息。您的文档负责指定在方法遇到错误时返回的内容

想到的另一种方法是

@throw

-

@catch

块；然而，在Objective-C

@throw

中，调用异常在计算上可能相当昂贵，通常只建议在真正异常的情况下这样做

编辑：哇，原来很多人对

@throw

抛出异常有很强的看法。总结一下关于这个问题的评论（非常有用）：

• 抛出异常通常应该处理程序员错误（应该永远不会发生的情况，等等）；异常不应用于普通错误处理。相反，请使用上面演示的

  error

  方法或NSNotification的post实例
• 如果您最终大量使用了

  @throw

  /

  @catch

  块，请非常小心它们周围的逻辑。Objective-C提供了很多方法来分离在其他线程中运行的方法，或者延迟执行等。在编写代码时，请非常小心地考虑所有这些可能性

最后，另一个非常有效的观点是：

• 如果确实使用传递给方法的

  错误

  对象，则返回值应指示该对象。不要尝试同时执行这两项操作（返回部分有效的对象并设置

  错误

  对象）

---

在ObjC中，试图@抛出一些将被捕获到您范围之外的内容也存在许多微妙的逻辑问题。例如，如果您被NSTimer调用，该怎么办？谁将捕获异常（并避免崩溃）？ObjC异常的功能不足以处理常见的ObjC习惯用法。它们通常只在处理编程错误时有用。如果您需要一个丰富的错误对象以供一般使用，那么NSError绝对是正确的选择。为了澄清这一点，Cocoa中的“真正的异常情况”几乎总是由程序员错误引起的，并且通常是不可恢复的，或者至少通过适当和必要的检查可以很容易地避免。在Objective-C中，仅仅为了向程序员发送信号而抛出异常并不是一种好的做法，现在甚至在Java中也不鼓励这样做，这不是因为计算成本，而是因为它大大增加了客户端代码的复杂性。继续这个概念，即使是集中式错误处理的思想也比Cocoa中的异常有更好的实现。我经常在一些中央错误处理对象观察到的NSN通知中抛出错误，以提供用户反馈。如果再加上NSError对重试逻辑的封装，这可以使“发布通知并返回”成为处理影响用户的错误的非常有效的解决方案。除了致命错误外，不要使用异常。从来没有。返回值必须明确指示错误与否。除非返回值指示错误，否则切勿触摸

error

参数。