Try-catch veya C ++ 'da hata işleme için ifs

İstisnalar oyun motoru tasarımında yaygın olarak mı kullanılıyor, yoksa eğer if ifadeleri kullanılarak daha çok tercih edilir mi? Örneğin istisnalar dışında:

try {
    m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
    m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
    m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
    m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
    m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
    m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );
} catch ... {
    // some info about error
}

ve ifs ile:

m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
if( m_fpsTextId == -1 ) {
    // show error
}
m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
if( m_cpuTextId == -1 ) {
    // show error
}
m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
if( m_frameTimeTextId == -1 ) {
    // show error
}
m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
if( m_mouseCoordTextId == -1 ) {
    // show error
}
m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
if( m_cameraPosTextId == -1 ) {
    // show error
}
m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );
if( m_cameraRotTextId == -1 ) {
    // show error
}

İstisnaların ifs'ten biraz daha yavaş olduğunu duydum ve istisnaları if-check yöntemiyle karıştırmamalıyım. Ancak, istisnalar dışında, bence sadece bir yöntem için çok ağır olsalar bile, her initialize () yönteminden veya benzer bir şeyden sonra tonlarca ifs'ten daha fazla okunabilir kodum var. Oyun gelişimi için uygunlar mı yoksa basit ifs ile başa çıkmak daha mı iyi?

Kısa cevap: Algılanabilir Hata Yönetimi 1 , Algılanabilir Hata Kullanımı 2 ve Mantıklı Hata Kullanımı 3'ü Niklas Frykholm tarafından okuyun. Aslında, sen blogdayken o blogdaki tüm makaleleri oku. Her şeye katılıyorum demeyeceğim ama çoğu altın.

İstisnaları kullanmayın. Bir sürü sebep var. En büyükleri listeleyeceğim.

Gerçekten daha yavaş olabilirler, ancak bu daha yeni derleyicilerde biraz azaltılabilir. Bazı derleyiciler, istisnaları tetiklemeyen kod yolları için "sıfır yükü istisnalarını" destekler (bu biraz yalan olsa da, istisna işleme için çalıştırılabilir / dll boyutunuzu şişirmek için hala fazladan veri kullanımı gerekir). Sonuç olarak, evet, istisnaları kullanmak daha yavaş ve performans açısından kritik kod yollarında kesinlikle bunlardan kaçınmalısınız. Derleyicinize bağlı olarak, etkin olmalarını sağlamak ek yük ekleyebilir. Her zaman kod boyutunu şişirir, daha ziyade, çoğu durumda, günümüzün donanımında performansı ciddi şekilde etkileyebilen önemli ölçüde şişirir.

İstisnalar, kodu çok daha kırılgan hale getirir . Bir grafik üzerinde (şu anda ne yazık ki bulamıyorum) temelde bir grafikte istisna güvenli kodla istisna güvenli olmayan kod yazmanın zorluğunu gösteren bir grafik var ve eski önemli ölçüde daha büyük bir çubuktur. Sadece istisnalar dışında çok sayıda ufak tefek şey var ve istisnaları güvenli görünen ama gerçekten değil gibi kod yazmanın birçok yolu var . Tüm C ++ 11 komitesi bile buna şaşırdı ve std :: unique_ptr komutunu doğru kullanmak için önemli bir yardımcı işlev eklemeyi unuttu ve bu yardımcı işlevlerde bile, bunları kullanmak için kullanmayacağından ve çoğu programcının kazandığından daha fazla yazı yazdı. Yapmazlarsa neyin yanlış olduğunu bile anlama.

Daha belirgin olarak, oyun endüstrisi için, bazı konsolların satıcı tarafından tedarik edilen derleyiciler / çalışma zamanları tamamen istisnaları tam olarak desteklemiyor, hatta hiç desteklemiyor. Kodunuz istisnalar kullanıyorsa, yine de bugün ve yaşta, yeni platformlara taşımak için kodunuzun bölümlerini yeniden yazmak zorunda kalabilirsiniz. (Söz konusu konsolların piyasaya sürülmesinden sonraki 7 yıl içerisinde bunun değişip değişmediğinden emin değilsiniz; istisnalar kullanmıyoruz, derleyici ayarlarında bile devre dışı bıraktıklarından, bu yüzden konuştuğum birinin yakın zamanda kontrol ettiğini bile bilmiyorum.)

Genel düşünme çizgisi oldukça açık: istisnai durumlar için istisnalar kullanın . Programınıza girdiğinde bunları kullanın. "Ne yapacağımı bilemiyorum, belki de başkası yapar, bu yüzden bir istisna atacağım ve ne olacağını göreceğim." Başka hiçbir seçenek mantıklı olmadığında bunları kullanın. Yanlışlıkla küçük bir hafıza sızdırması veya bir kaynağı temizleyememeniz veya uygun akıllı tutamaçların kullanımını karıştırdığınızdan emin olmamanız durumunda bunları kullanın. Diğer tüm durumlarda, onları kullanmayın.

Örnekteki gibi bir kodla ilgili olarak, sorunu çözmenin birkaç başka yolu vardır. En sağlamlarından biri - basit örneğinizde mutlaka en ideal olmasa da - monadik hata türlerine yaslanmaktır. Yani, createText () bir tamsayı yerine özel bir tanıtıcı türü döndürür. Bu tutamaç türü, metni güncellemek veya kontrol etmek için erişim sağlayıcılara sahiptir. Tutamaç bir hata durumuna getirildiyse (createText () başarısız oldu), daha sonra tutamağa yapılan çağrılar sessizce başarısız olur. Ayrıca, hatalı olup olmadığını ve varsa son hatanın ne olduğunu görmek için tanıtıcıyı sorgulayabilirsiniz. Bu yaklaşım diğer seçeneklerden daha fazla ek yüke sahiptir, ancak oldukça sağlamdır. Tek bir işlemin üretimde başarısız olabileceği, ancak yapamadığınız / kazanamadığınız / kazanamadığınız bazı bağlamlarda uzun bir işlem dizisi uygulamanız gerektiğinde kullanın.

Monadik hata işlemenin uygulanmasına bir alternatif, özel tanıtıcı nesneler kullanmak yerine, bağlamsal nesnedeki yöntemleri geçersiz tanıtıcı kimlikleriyle incelikle ele almasıdır. Örneğin, createText () başarısız olduğunda -1 döndürürse, o zaman bu tutamaçlardan birini alan m_statistics işlevine yapılan çağrılar, -1 iletilirse dikkatlice çıkmalıdır.

Aynı şekilde, hata basma işlemini gerçekten başarısız olan işlevin içine de koyabilirsiniz. Örneğinizde, createText () muhtemelen neyin yanlış gittiği hakkında daha fazla bilgiye sahip olduğundan, günlüğe daha anlamlı bir hata verebilir. Bu durumda, hatayı işleme / yazdırma işleminin arayanlara iletilmesinin çok az yararı vardır. Arayanların kullanımı özelleştirmesi (veya bağımlılık enjeksiyonunu kullanması) gerektiğinde bunu yapın. Bir hata günlüğe kaydedildiğinde ortaya çıkabilecek bir oyun içi konsola sahip olmanın iyi bir fikir olduğunu ve burada da yardımcı olacağını unutmayın.

Herhangi bir aklı başında bir ortamda başarısız olmasını beklemeyeceğiniz aramalar için en iyi seçenek (yukarıdaki bağlantılı makalelerde sunulan) - bir istatistik sistemi için metin blobları oluşturma eylemi gibi - sadece fonksiyona sahip olmaktır. bu başarısız oldu (örneğinizdeki createText) iptal edildi. Bir şey tamamen kazanılmadığı sürece createText () 'in üretimde başarısız olmayacağından emin olabilirsiniz (örneğin, kullanıcı yazı tipi veri dosyalarını silmiş veya bir nedenden dolayı sadece 256 MB belleğe sahip vs.). Bu vakaların çoğunda, başarısızlık gerçekleştiğinde yapılacak iyi bir şey bile yoktur. Bellek yetersiz? Kullanıcıya OOM hatasını göstermek için hoş bir GUI paneli oluşturmak için gerekli bir tahsis bile yapamayabilirsiniz. Eksik fontlar? Kullanıcıya hataları göstermeyi zorlaştırır. Neyin yanlışsa,

Siz sadece (a) hatayı bir günlük dosyasına kaydettiğiniz ve (b) sadece normal kullanıcı eylemlerinden kaynaklanmayan hatalar üzerine yaptığınız sürece, kilitlenme tamamen iyidir.

Aynı şeyi pek çok sunucu uygulaması için söyleyemem, kullanılabilirliğin kritik olduğu ve bekçi izleme sisteminin yeterli olmadığı, ancak oyun istemcisi geliştirmeden oldukça farklı olduğu söylenebilir. Ayrıca, diğer dillerin istisna işleme olanakları, yönetilen ortamlar olduğundan ve C ++ 'nın istisna güvenliği sorunlarına sahip olmadığından C ++ C gibi ısırma eğilimi göstermediğinden, sizi C / C ++ kullanmaya zorla yönlendiririm. Sunucular, oyun müşterileri gibi asgari gecikme garantilerinden çok paralellik ve verim üzerinde yoğunlaşmaya meyilli olduğu için performans kaygıları da hafifletilir. Atıcılar ve benzerleri için aksiyon oyunu sunucuları bile, C # ile yazıldığında oldukça iyi işleyebilir, çünkü, örneğin, FPS istemcilerin yapma eğiliminde olduğu gibi donanımı nadiren zorluyorlar.

Donald Knuth’un eski bilgeliği:

“Küçük verimsizlikleri unutmalıyız, zamanın% 97'sini söyleyelim: erken optimizasyon tüm kötülüklerin kaynağıdır.”

Bunu büyük bir poster olarak yazdırın ve ciddi programlama yaptığınız her yere asın.

Yani bile eğer deneme / yakalama biraz daha yavaş olduğu zaman ben varsayılan olarak kullanmak olacaktır:

• Kod mümkün olduğu kadar okunaklı ve anlaşılabilir olmalıdır. Sen belki bir kez kod yazmak ama olacak iyileştirilmesi için, anlamak için, diğer kod hata ayıklama için, bu kod hata ayıklama için bunu birçok defa daha okumak, ...

• Performansa göre doğruluk. İf / else işlemlerini doğru yapmak önemsiz değildir. Örneğinizde yanlış yapıldı, çünkü bir hata gösterilemiyor, birden fazla gösteriliyor. Eğer / / / / sonra basamaklı kullanmanız gerekir.

• Tutarlı kullanımı daha kolay: Deneyin / yakalayın, her satırda hataları kontrol etmeniz gerekmeyen bir stili benimseyin. Diğer yandan: One else / if ve kod kudreti batık tahribat eksik. Tabii ki sadece yeniden üretilemeyen koşullarda.

Yani son nokta:

İstisnaların ifşaya göre biraz daha yavaş olduğunu duydum

Bunu 15 yıl önce duydum, son zamanlarda güvenilir kaynaklardan duymadım. Derleyiciler iyileşmiş olabilir veya her neyse.

Ana nokta şudur: Erken optimizasyon yapmayın. Yalnızca, eldeki kodun, yoğun olarak kullanılan bazı kodların sıkı iç halkası olduğunu ve anahtarlama stilinin performansı önemli ölçüde iyileştirdiğini kanıtlamak için bunu yapabilirsiniz . Bu% 3 durumdur.

Bu soruya gerçekten çok iyi bir cevap verdim, ancak özel durumunuzda kod okunabilirliği ve hata kurtarma hakkında bazı düşünceler eklemek istiyorum.

Kodunuzun gerçekten böyle görünebileceğine inanıyorum:

m_fpsTextId = m_statistics->createText( "FPS: 0", 16, 20, 20, 1.0f, 1.0f, 1.0f );
m_cpuTextId = m_statistics->createText( "CPU: 0%", 16, 20, 40, 1.0f, 1.0f, 1.0f );
m_frameTimeTextId = m_statistics->createText( "Frame time: 0", 20, 20, 60, 1.0f, 1.0f, 1.0f );
m_mouseCoordTextId = m_statistics->createText( "Mouse: (0, 0)", 20, 20, 80, 1.0f, 1.0f, 1.0f );
m_cameraPosTextId = m_statistics->createText( "Camera pos: (0, 0, 0)", 40, 20, 100, 1.0f, 1.0f, 1.0f );
m_cameraRotTextId = m_statistics->createText( "Camera rot: (0, 0, 0)", 40, 20, 120, 1.0f, 1.0f, 1.0f );

İstisna yok, eğer yok. Hata raporlaması yapılabilir createText. Ve createTextgeri dönüş değerini kontrol etmenizi gerektirmeyen varsayılan bir doku kimliği döndürebilir, böylece kodun geri kalanı da aynı şekilde çalışır.