引发异常的方法

虽然在Objective-C中编程，但我偶尔会有方法抛出一个我并不期待的异常。引发异常的方法

有了事后的看法，我可以看出它为什么会抛出异常，并且通常解决问题会导致更好的代码。

但是，提前知道什么方法会抛出异常以及在什么情况下会很方便。

例如：作为字符串包含小于42个字符

NSString *aString; 
aString = @"Less than 42 characters."; 
[aString substringToIndex:42];

将抛出异常。

而且这样的：

NSString *aString = @"This is a string."; 
NSString *bString = nil; 
aString = [NSString stringByAppendingString:bString];

同样会崩溃的bString为零。

还有其他的例子吗？

来源

2011-04-27 Snowcrash

不是一个愚蠢的，但几乎：http://stackoverflow.com/questions/4310560/usage-of-nsexception-in-iphone-apps具体来说：**不要使用异常来表示任何东西，但不可恢复的错误** （有关详细信息，请参阅q/a - 底线：不要使用例外来捕获范围错误） – bbum 2011-04-27 15:06:39

但是，提前知道什么方法会抛出异常以及在什么情况下会很方便。

它在文档中告诉你。

来源

2011-04-27 13:28:52 kubi

+1那么如何：文档完成其工作。 – JeremyP 2011-04-27 14:21:17

如果言外之意是，你应该依靠你的解析代码这样的例外，不这样做.... – bbum 2011-04-27 15:07:59

虽然Objective-C的不支持的例外，他们很少使用。他们面临的最大问题是在释放对象之前跳出上下文所导致的内存泄漏（尽管这在GC环境中不再是问题）。

异常主要用于Objective-C中的致命情况，它们很少用于可恢复的错误。为此，方法通过指针指针，如+[NSURLConnection sendSynchronousRequest:returningResponse:error:]。

因此，只要文档没有明确说明有关异常的任何信息，就不需要太多关心它们。

你的第一个例子永远是抛出一个异常顺便说一句，作为的NSString没有一个方法subString:。

来源

2011-04-27 13:32:08 DarkDust

不要认为内存泄漏不再是一个问题，如果你正在使用GC。 “malloc”和释放的内存仍然可能泄漏，CF对象和文件描述符也可以泄漏。 – JeremyP 2011-04-27 14:28:45

@JeremyP：对，忽略了。无论如何，GC是用于sissies的;-) – DarkDust 2011-04-27 14:42:18

有许多其他原因不使用异常，最大的缺点是在调用过程中抛出异常是未定义的行为。顺便说一句：在许多常见情况下，Mac OS X GC实际上比非GC代码快。更快，更小的内存占用，更少的代码让我维护？是的，请。 – bbum 2011-04-27 15:05:22

引发异常的方法

回答

相关问题