2009-05-25 20 views
12

Bir init yönteminde düzgün bir şekilde başarısız olmanın nasıl olduğunu okuyordum ve dokümanlar birbirleriyle aynı fikirde değil gibi görünüyor. Birisi bir istisna atmanızı önerirken, diğerleri temizlemeyi ve geri dönmeyi tavsiye ediyor. Mevcut en iyi uygulama nedir?[self release], [self dealloc] veya [super dealloc]?

cevap

16

Genel olarak kabul edilen uygulamanın başarısızlığa geri dönmek olduğuna inanıyorum. Ama bir sızıntı önlemek için kendini serbest bırakmak istiyoruz: istisnalarla ilgili

-(id)init 
{ 
    if (self = [super init]) { 
    ... 
    if (thingsWentWrong) { 
     [self release]; 
     return nil; 
    } 
    ... 
    } 
    return self; 
} 
+0

Geri bildirim adamlar için teşekkürler. Yaptığım şey buydu ve doğru yaklaşım olduğu düşünülüyordu, ancak dokümanlardaki diğer iki yönteme yapılan göndermeler, benim bilmem gereken bazı özel durumlar olabileceğini düşünüyordu. – Kevin

0

Her zaman kullandığım yöntem temizleniyor ve geri dönüyor. Soru başlığından bahsettiğiniz üç yöntem, çağrı hiyerarşisinde segfaultların daha yüksek olmasına neden olurken, geri dönen nil olmaz. Apple'ın kendilerinin başarısızlıktan geri dönmek için söylediklerine inanıyorum. Tutarsızlıkları nerede buluyorsunuz?

+2

Basit bir şekilde geri dönme, belleği ayırma çağrısı, çünkü bir çağrıyı alıkonan bir nesne oluşturacaktır. –

+0

Bellek sızıntısı, kaçınmak istediğim şeydir. docs için – Kevin

+0

Bağlantılar: başlatma sırasında Hata Tespiti - http://tr.im/mlyA bir Initializer Uygulanması - Sen fark edeceksiniz http://tr.im/mlyX ikinci linkte örnek kodu altında bunun yerine bir istisna atmanızı öneriyorlar. Eminim ki şu anki en iyi uygulama değil. – Kevin

6

Kakao felsefesi sadece bir yönteme yanlış argüman geçirerek gibi programcı hatalardır durumlarda atılmalı olmasıdır. Başka bir şey ters giderse, yöntem sadece NO veya sıfır vermeli ve bir NSError ** "çıkış" parametresi aracılığıyla ayrıntıları bildirmelidir.

Bu, aşağıdaki yordamları içerir. Hata durumu bitmiş üründe yasal olarak meydana gelebilecek bir şeyse, yöntem kendini serbest bırakmalı (sızıntıyı önlemek için) ve geri dönmelidir.

9

Doğru çözümler (istisnalar ve/veya [self release]; return nil;) kapsanmıştır, yanlış çözümleri ele alacağım.

Doğrudan dealloc göndermeyin. Bu release'un işi. (Ve kodunuz GC altında çalışıyorsa, dealloc geçersizdir ve yalnızca hangi sorunların neden kaynaklanacağı konusunda spekülasyon yapabilirdim.)

Çiftleri doğrudan göndermek için super'u kullanmayın. Bu, kendi dealloc uygulamanızın üzerinden geçecektir.

İlgili konular