iOS中的exception处理
阅读文档并浏览Apple示例代码（以及那里提供的大多数第三方Objective-C代码），我得到的印象是你不应该使用try / catch和“traditional / C”进行exception处理。方法。
最近我正在阅读Amazons AWS iOS SDK并注意到他们已经大量使用了旧方法。
这对我来说是一种解脱，因为我总是觉得我需要确保在使用其他人或二进制库编写的代码（我的意思是谷歌分析二进制文件）时特别捕获exception。 我的问题是，有没有理由避免在iOS上“传统”的例外处理，或者这不是一个有品位的Objective-C做法？
完全有理由避免在iOS上出现exception。
iOS上的例外明确保留用于无法恢复的灾难性故障。 它们不用于执行捕获和恢复类型的操作。
重要提示：您应该保留使用编程exception或意外的运行时错误，例如越界集合访问，尝试改变不可变对象，发送无效消息以及丢失与窗口服务器的连接。 在创建应用程序时而不是在运行时，通常会使用exception处理这些类型的错误。
如果您具有使用exception来处理错误条件的现有代码体（例如第三方库），则可以在Cocoa应用程序中按原样使用代码。 但是您应该确保任何预期的运行时exception都不会从这些子系统中逃脱，最终会出现在调用者的代码中。 例如，解析库可能在内部使用exception来指示问题，并允许快速退出可能深度递归的解析状态; 但是，您应该注意在库的顶层捕获此类exception，并将它们转换为适当的返回代码或状态。
这导致了两个问题（其中包括）：
-
你不能通过系统框架代码框架@throwexception。 行为未定义。
-
如果您设计代码以使用exception，则代码与系统之间的边界会出现大量阻抗不匹配。 这不仅会让人感到尴尬，而且随着边界的转变，它将使所有未来的维护和重构操作变得更加困难。 它还将使与系统集成变得更加困难。
请注意，如果AWS SDK通过系统框架拥有的堆栈框架抛出exception，那么它就是错误的。
bbum是现货。 看起来AWS iOS SDK正朝着基于NSError的方法发展，以便将来发布。 截至目前，他们提供了停止例外和使用NSErrors的机制。
#import // put this in didFinishLaunching [AmazonErrorHandler shouldNotThrowExceptions];
更多细节在这里：
https://mobile.awsblog.com/post/Tx2PZV371MJJHUG/How-Not-to-Throw-Exceptions-with-the-AWS-SDK-for-iOS