iOS中的异常处理 [英] Exception Handling in iOS

问题描述

阅读文档并浏览Apple示例代码（以及那里提供的大多数第三方Objective-C代码），我得到的印象是您不应该使用try / catch和传统进行异常处理/ C方法。

最近我正在阅读Amazons AWS iOS SDK并注意到他们已经大量使用了旧方法。

这对我来说是一种解脱，因为我总觉得我当我使用其他人或二进制库编写的代码时（我的意思是谷歌分析二进制文件），我需要确保特别捕获异常。
我的问题是，有没有理由避免在iOS上传统的例外处理，或者说这不是一个有品位的Objective-C做法？

Reading the documentation and going through the Apple sample codes (and most of the third party Objective-C code available out there), I get the impression that you are not supposed to do exception handling by using try/catch and "traditional/C" methods.
Recently I was reading Amazons AWS iOS SDK and noticed that they have used the old method liberally.
This was a relief for me because I always felt that I need to make sure I catch the exception specially when I am using code written by someone else or binary libraries (I mean things like Google Analytics binaries). My question is, is there any reason to avoid "traditional" exception handeling" on iOS, or it is just not a tasteful Objective-C practice to do that?

推荐答案

完全有理由避免在iOS上出现异常。

There is every reason to avoid exceptions on iOS.

iOS上的例外明确保留用于无法从中恢复的灾难性故障它们不是用来进行捕获和恢复类型的操作。

重要提示：你应该保留使用异常编程或
意外的运行时错误，例如越界集合访问，
尝试改变不可变对象，发送无效消息，
丢失与窗口服务器的连接你通常会把a b $ b这些种类的错误当作a来处理pplication是
而不是在运行时创建的。

Important: You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.

如果你有一个现有的代码体（例如第三方库）
使用处理错误条件的异常，您可以在Cocoa应用程序中使用代码
as-is。但是你应该确保任何
预期的运行时异常都不会从这些子系统中逃脱，并且
最终会出现在调用者的代码中。例如，解析库可能在内部使用
异常来指示问题，并从可能深度递归的解析状态中快速退出
;但是，
应注意在
库的顶层捕获此类异常，并将它们转换为适当的返回代码或状态。

If you have an existing body of code (such as third-party library) that uses exceptions to handle error conditions, you may use the code as-is in your Cocoa application. But you should ensure that any expected runtime exceptions do not escape from these subsystems and end up in the caller’s code. For example, a parsing library might use exceptions internally to indicate problems and enable a quick exit from a parsing state that could be deeply recursive; however, you should take care to catch such exceptions at the top level of the library and translate them into an appropriate return code or state.

这导致两个问题（其中包括）：

This leads to two issues (amongst others):

• 你不能@throw通过系统框架代码框架的异常。行为未定义。

• you can't @throw an exception through a frame of system framework code. The behavior is undefined.

如果您设计代码以使用异常，则代码与系统之间的边界会出现大量阻抗不匹配。这不仅会让人感到尴尬，而且随着边界的转变，它将使所有未来的维护和重构操作变得更加困难。它还会使与系统集成变得更加困难。

if you design your code to use exceptions, you'll have a massive impedance mismatch at the border between your code and the system. Not only will this be awkward, it'll make all future maintenance and refactoring operations more difficult as that border shifts. It will also make it more difficult to integrate with the system.

请注意，如果AWS SDK通过以下方式抛出异常堆栈框架由系统框架拥有，然后它做错了。

Note that if the AWS SDK is throwing exceptions through stack frame's owned by the system frameworks, then it is doing it wrong.

这篇关于iOS中的异常处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！