3 回答

TA貢獻1911條經驗 獲得超7個贊
例如:
[[NSData alloc] initWithContentsOfFile:@"this/path/doesn't/exist/"];
[[NSImage alloc] initWithContentsOfFile:@"unsupportedFormat.sjt"];
[NSImage imageNamed:@"AnImageThatIsntInTheImageCache"];
... 等等。(注意:如果文件不存在,NSData可能會引發異常)。在很多地方,出現問題時返回零是預期的行為,因此,出于一致性的考慮,標準的做法是一直不停地檢查零。

TA貢獻1851條經驗 獲得超3個贊
這個特殊的習慣用法是標準的,因為它適用于所有情況。
雖然不常見,但在某些情況下...
[super init];
...返回一個不同的實例,因此需要分配給self。
在某些情況下,它將返回nil,因此需要執行nil檢查,以便您的代碼不會嘗試初始化不再存在的實例變量插槽。
底線是使用的已記錄的正確模式,如果不使用它,那就錯了。

TA貢獻2051條經驗 獲得超10個贊
我認為,在大多數類中,如果[super init]的返回值是nil,并且按照標準做法的建議進行檢查,然后過早返回(如果是nil),則基本上您的應用仍無法正常工作。如果您考慮一下,即使那里(self!= nil)檢查存在,為了使您的班級正常運行,您實際上確實有99.99%的時間需要self不為nil?,F在,假設,由于任何原因,[super init] 確實返回了nil,基本上您對nil的檢查基本上是將buck傳遞給了您的類的調用者,無論如何它都可能失敗,因為它自然會假定調用為成功。
基本上,我得到的是99.99%的時間,if(self!= nil)不會給您帶來任何更大的健壯性,因為您只是將責任推給了調用者。為了真正能夠可靠地處理此問題,實際上需要在整個調用層次結構中進行檢查。即便如此,它唯一能買到的是您的應用程序將更加干凈/健壯地失敗。但是它仍然會失敗。
如果某個庫類由于[super init]的結果而任意決定返回nil,那么您無論如何都會感到煩惱,這更多地表明該庫類的編寫者犯了一個實現錯誤。
我認為當應用程序在有限得多的內存中運行時,這更像是一種傳統的編碼建議。
但是對于C級代碼,我通常仍將對照NULL指針檢查malloc()的返回值。而對于Objective-C,直到我發現相反的證據,我認為我通常會跳過if(self!= nil)檢查。為什么會有差異?
因為在C和malloc級別上,您實際上實際上可以部分恢復。我認為在Objective-C中,在99.99%的情況下,如果[super init]確實返回nil,即使您嘗試處理它,也基本上會感到滿意。您不妨讓應用程序崩潰并處理后果。
- 3 回答
- 0 關注
- 506 瀏覽
添加回答
舉報