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

问题描述

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

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

这对我来说是一个救济，因为我一直觉得我当我使用由别人或二进制库编写的代码（我的意思是像Google Analytics（分析）二进制文件）时，需要特别注意异常。
我的问题是，是否有任何理由在iOS上避免传统的异常处理，或者这不是一个有品味的Objective-C做法吗？

解决方案

有理由避免iOS上的异常。

iOS上的异常显式保留用于灾难性故障，无法从它们不是用来做捕捉和恢复类型的操作。

重要提示：您应该保留使用异常编程或
意外的运行时错误，例如超出范围的收集访问，
尝试突变不可变对象，发送无效消息，
丢失与窗口服务器的连接你通常会照顾
这些类型的错误，当一个a应用程序是
而不是在运行时创建。

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

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

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




• 如果您设计代码以使用异常，那么您的代码和系统之间的边界将阻塞不匹配。不仅这将是尴尬的，它将使所有未来的维护和重构操作更加困难，因为边界转移。

请注意，如果AWS SDK正在抛出异常堆栈框架由系统框架所有，那么它做错了。

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 handeling 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?

解决方案

There is every reason to avoid exceptions on iOS.

Exceptions on iOS are explicitly reserved for catastrophic failure that cannot be recovered from. They are not intended to be used to do catch-and-recover type operations.

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.

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):

• 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.

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屋！