objective-c - Cocoa 异常策略背后的基本原理是什么——或者为什么只对程序员错误使用异常？

Question

Cocoa 异常策略背后的基本原理是什么——或者为什么只对程序员错误使用异常？

我知道异常曾经是相当昂贵的，所以人们不想过度使用它们。但这随着现代运行时而改变，它是零成本异常。我也明白使用异常来进行一般控制流并不是一个好主意，因为它可能导致代码很难理解。

但是为什么要使用异常来指示程序员的错误呢？对于这种情况，记录一条消息后跟 abort() 应该就足够了。为什么我应该编写一个 @catch(...) block 来处理程序员错误而不是修复实际错误？我一直在思考这个问题，但我还没有发现对程序员错误的异常的任何合理使用。

(作为旁注/问题:我已经编写了一个递归下降解析器，并且我计划在那里使用异常来处理错误。对我来说似乎比为每个单独的添加一个 out 参数更合理在那里运行并手动检查所有地方的错误。当然，我会捕获我在从外部调用的顶级方法中抛出的任何异常。有人认为这是对异常的不良使用吗？)

更新:真正的问题

感谢您到目前为止的所有回答。它们都是真的，但实际上并没有回答我的问题。所以我想我不是很清楚，对此感到抱歉。所以这是真正的问题:

为什么 Cocoa 会为程序员错误(或断言)抛出异常？ 不应该捕获它们，实际上编写代码来处理调用堆栈中某个地方的程序员错误并不是无论如何是个好主意。在我看来，异常(exception)是一种浪费。只需记录错误并调用 abort()(退出程序)就足够了。那么实际抛出异常有什么好处呢？

我理解为什么通常不使用和不鼓励使用异常 - Cocoa 的大部分内容都不是异常安全的。这不是这里的问题。我希望我现在说清楚了。

Answer 1

Why should I write a @catch(...) block to handle a programmer error instead of fixing the actual mistake?

在大多数情况下，您不会。在 Objective-C 中，您通常不处理异常。如果发生异常，它会导致崩溃，然后您修复该错误——希望您能在测试期间发现这一点。

当然，在某些情况下这是行不通的。也许你做除了异常并且你可以解决它，所以你捕获它。或者有一些罕见的 API 会抛出异常而不是使用错误对象。

老实说，我很少在我的 Objective-C 代码中使用 try/catch。

至于基本原理，我认为这主要是由于 Objective-C 的 C 继承。早在 80 年代初开发 Objective-C 时，异常就有点"new"(即，还没有出现在许多主流语言中)，而 Objective-C 更迎合了使用 NULL 的 C 传统或用于指示错误的输出参数。