İstisna spesifikasyonları neden kötü?

Yaklaşık 10 yıl önce okula geri döndüğünde, size istisna belirtecilerini kullanmayı öğretiyorlardı. Geçmişim onlardan biri olduğu için zorlamadıkça inatla C ++ 'dan kaçınan Torvaldish C programcıları olduğu için, sadece sporadik olarak sadece C ++' a giriyorum ve bunu yaptığımda hala istisna belirtecilerini kullanıyorum.

Bununla birlikte, C ++ programcılarının çoğunluğu istisna belirleyicileri üzerine kaşlarını çatıyor gibi görünüyor. Tartışmayı ve çeşitli C ++ gurularının argümanlarını okudum, bunun gibi . Anladığım kadarıyla, üç şeye kadar kaynar:

1. İstisna belirticileri, dilin geri kalanıyla tutarsız olan bir tür sistemi kullanır ("gölge tür sistemi").
2. Bir istisna belirteci olan işleviniz, sizin belirttiğiniz dışında başka bir şey atarsa, program kötü, beklenmedik şekillerde sonlandırılır.
3. İstisna belirteçleri yaklaşmakta olan C ++ standardında kaldırılacak.

Burada bir şey mi eksik veya tüm nedenler bunlar mı?

Kendi görüşlerim:

1): Peki ne olmuş. C ++ muhtemelen şimdiye kadar yapılmış en tutarsız programlama dilidir, sözdizimi açısından. Makrolar, genel / etiketler, tanımlanmamış / belirtilmemiş / / uygulama-tanımlanmış davranışların belirsizliği (hoard?), İyi tanımlanmamış tamsayı türleri, tüm kapalı tip promosyon kuralları, arkadaş, oto gibi özel durumlu anahtar kelimelerimiz var. , kayıt ol, açık ... Ve benzeri. Birileri muhtemelen C / C ++ 'da tuhaflıktan birkaç kalın kitap yazabilir. Öyleyse insanlar neden dilin çok daha tehlikeli özelliklerine kıyasla küçük bir kusur olan bu özel tutarsızlığa karşı tepki gösteriyorlar?

2 ile ilgili olarak): Bu benim sorumluluğum değil mi? C ++ 'da ölümcül bir hata yazabileceğim başka birçok yol var, bu özel durum neden daha da kötü? throw(int)Yazmak ve sonra Crash_t'yi atmak yerine, işlevimin int için bir işaretçi döndürdüğünü, sonra da vahşi, açık bir typecast oluşturup bir işaretçiyi Crash_t'ye döndürdüğünü iddia edebilirim. C / C ++ 'ın ruhu her zaman sorumluluğun çoğunu programlayıcıya bırakmak olmuştur.

Peki ya avantajlar? En açık olanı, eğer fonksiyonunuz açıkça belirttiğinizden başka bir tür atmaya çalışırsa, derleyici size bir hata verecektir. Standardın bu konuda açık olduğuna inanıyorum (?). Hatalar, yalnızca fonksiyonunuz, sırayla yanlış tipi atan diğer fonksiyonları çağırdığında ortaya çıkar.

Deterministik, gömülü C programları dünyasından gelince, bir fonksiyonun bana ne atacağını kesinlikle bilmeyi tercih ederim. Dilde bunu destekleyen bir şey varsa, neden kullanmıyorsunuz? Alternatifler gibi görünüyor:

void func() throw(Egg_t);

ve

void func(); // This function throws an Egg_t

Sanırım, arayan kişinin ikinci durumda denemeyi uygulamaya koymasını görmezden gelmesi / unutması gibi büyük bir şans olduğunu düşünüyorum.

Anladığım kadarıyla, bu iki formdan biri aniden başka bir istisna yaratmaya karar verirse, program çökecektir. İlk durumda, başka bir istisna atmasına izin verilmediğinden, ikinci durumda, hiç kimse bir SpanishInquisition_t atmayı beklememesi nedeniyle ve bu nedenle ifadesi olması gerektiği yerde yakalanmadı.

İkincisi durumunda, programın en üst seviyesinde son çare avı (...) yapmak gerçekten bir programın çökmesinden daha iyi görünmüyor: "Hey, programınızın herhangi bir yerinde garip, işlenmeyen bir istisna attı . ". İstisnanın atıldığı yerden uzakta olduğunuzda programı kurtaramazsınız, yapabileceğiniz tek şey programdan çıkmaktır.

Ve kullanıcının bakış açısından, işletim sisteminden "Program sonlandı. 0x12345 adresinde Blablabla" diyen kötü bir mesaj kutusu veya "İşlenmeyen istisna: myclass" yazan programınızdan kötü bir mesaj kutusu alırsa daha az umursayamazlardı. func.something". Böcek hala orada.

Yaklaşan C ++ standardı ile istisna belirteçlerini terk etmekten başka seçeneğim kalmayacak. Ancak "Kutsal Hazretleri bunu belirtti ve bu yüzden öyle" yerine, neden kötü olduklarına dair sağlam bir argüman duymayı tercih ederim. Belki de onlara karşı listelediklerimden daha fazla argüman var veya belki de benim düşündüğümden daha fazla var?

İstisna özellikleri kötüdür, çünkü zayıf bir şekilde uygulanırlar ve bu yüzden aslında çok fazla bir şey yapmazlar ve aynı zamanda UB'yi çağırmak yerine () sonlandırmak için beklenmedik istisnaları kontrol etmek için çalışma zamanını zorladıkları için de kötüdürler. bu, önemli miktarda performansı israf edebilir.

Sonuç olarak, istisna özellikleri, kodu gerçekten daha güvenli hale getirecek dilde yeterince güçlü bir şekilde uygulanmadı ve bunları belirtilen şekilde uygulamak büyük bir performans kaybıydı.

Hiç kimsenin onları kullanmamasının bir nedeni, temel varsayımınızın yanlış olmasıdır:

“En açık [avantaj], işleviniz açıkça belirttiğinizden başka bir tür atmaya çalışırsa, derleyici size bir hata verecektir.”

struct foo {};
struct bar {};

struct test
{
    void baz() throw(foo)
    {
        throw bar();
    }
};

int main()
{
    test x;
    try { x.baz(); } catch(bar &b) {}
}

Bu program hiçbir hata veya uyarı içermez .

Ayrıca, istisna yakalanmış olsa bile , program hala sona ermektedir.

Düzenleme: Sorunuzdaki bir noktaya cevap vermek için, catch (...) (veya daha iyisi, catch (std :: exeption &) veya diğer temel sınıf ve ardından catch (...)) yapmasanız bile yine de kullanışlıdır. Neyin yanlış gittiğini tam olarak bil.

Kullanıcınızın "kaydet" için bir menü düğmesine bastığını düşünün. Menü düğmesinin işleyicisi, uygulamayı kaydetmeye davet eder. Bu sayısız nedenden ötürü başarısız olabilir: dosya yok olan bir ağ kaynağındaydı, salt okunur bir dosya vardı ve kayıt edilemiyordu, vb. Ancak işleyici bir şeyin neden başarısız olduğunu gerçekten umursamıyor; sadece başarılı veya başarısız olmasını umursar. Eğer başarırsa, her şey yolunda. Başarısız olursa, kullanıcıya söyleyebilir. İstisnanın kesin yapısı alakasızdır. Ayrıca, uygun ve istisnai güvenli bir kod yazarsanız, bu tür herhangi bir hatanın sisteminizi çökertmeden ilerletebileceği anlamına gelir - hatayı umursamayan kodlar için bile. Bu, sistemi genişletmeyi kolaylaştırır. Örneğin, şimdi bir veritabanı bağlantısı aracılığıyla kaydedersiniz.

Anders Hejlsberg ile yapılan bu röportaj oldukça ünlü. İçinde C # tasarım ekibinin neden ilk başta kontrol edilen istisnaları attığını açıklıyor. Özet olarak, iki ana neden vardır: sürümlenebilirlik ve ölçeklenebilirlik.

OP'nin C ++ 'ya odaklandığını biliyorum, oysa Hejlsberg C #' yı tartışıyor, ancak Hejlsberg 'in yaptığı noktalar da C ++' a mükemmel bir şekilde uygulanabilir.