İstisnalar için sözleşmeleri nasıl oluşturabilir ve uygulayabilirim?

Takım isSuccessfulliderimi, hata kodu ile bir bool veya enum döndürmek yerine C ++ 'da istisnalar kullanmaya izin vermeye ikna etmeye çalışıyorum . Ancak onun bu eleştirisine karşı koyamam.

Bu kütüphaneyi düşünün:

class OpenFileException() : public std::runtime_error {
}

void B();
void C();

/** Does blah and blah. */
void B() {
    // The developer of B() either forgot to handle C()'s exception or
    // chooses not to handle it and let it go up the stack.
    C();
};

/** Does blah blah.
 *
 * @raise OpenFileException When we failed to open the file. */
void C() {
    throw new OpenFileException();
};

1. B()Fonksiyonu çağıran bir geliştirici düşünün . Belgelerini kontrol eder ve istisnalar döndürmediğini görür, bu yüzden hiçbir şey yakalamaya çalışmaz. Bu kod programın üretimde çökmesine neden olabilir.

2. C()Fonksiyonu çağıran bir geliştirici düşünün . Belgeleri kontrol etmiyor, bu yüzden istisnalar yakalamıyor. Çağrı güvenli değil ve programın üretimde çökmesine neden olabilir.

Ancak hataları bu şekilde kontrol edersek:

void old_C(myenum &return_code);

Bu işlevi kullanan bir geliştirici, bu argümanı sağlamazsa derleyici tarafından uyarılır ve "Aha, kontrol etmem gereken bir hata kodu döndürür" derdi.

Bir çeşit sözleşme yapılması için istisnaları nasıl güvenle kullanabilirim?

Bu, istisnaların meşru bir eleştirisidir. Genellikle bir kod döndürme gibi basit hata işlemeden daha az görülürler. Ve bir “sözleşmeyi” yürürlüğe koymanın kolay bir yolu yoktur. Bunun amacı, istisnaların daha yüksek bir seviyede yakalanmasına izin vermektir (her istisnayı her seviyede yakalamak zorundaysanız, bir hata kodu döndürmekten ne kadar farklıdır?). Bu da kodunuzun, uygun şekilde işlemeyen başka bir kod tarafından çağrılabileceği anlamına gelir.

İstisnaların olumsuz yanları vardır; Fayda temelli bir dava açmak zorundasınız.
: Ben yararlı olan bu iki makale buldum istisnalar gerekliliğini ve istisnalar dışında her şey yanlış. Ayrıca, bu blog yazısı C ++ 'a odaklanan istisnalar hakkında birçok uzman görüşü sunmaktadır . Uzman görüşü istisnalar lehine görünmekle birlikte, net bir fikir birliğinden uzaktır.

Takım liderini ikna etmek gelince, bu seçim yapmak için doğru savaş olmayabilir. Özellikle eski kodlarla değil. Yukarıdaki ikinci linkte belirtildiği gibi:

İstisnalar, istisnai olarak güvenli olmayan herhangi bir kodla çoğaltılamaz. Bu nedenle istisnaların kullanılması, projedeki tüm kodların istisna güvenliğinde olması gerektiği anlamına gelir.

Ağırlıklı olarak muhtemelen edilir etmediğini bir projeye istisnalar kullanan kod biraz ekleme değil bir gelişme olacak. Aksi takdirde iyi yazılmış kodlarda istisnalar kullanmamak, feci bir sorundan uzaktır; Uygulamaya ve sorduğunuz uzmana bağlı olarak hiç sorun olmayabilir. Savaşlarını seçmelisin.

Bu muhtemelen üzerinde çalışacağım bir tartışma değil - en azından yeni bir proje başlayana kadar. Yeni bir projeniz olsa bile, herhangi bir eski kod tarafından kullanılacak mı veya kullanılacak mı?

Kelimenin tam anlamıyla bu konuda yazılmış tüm kitaplar var, bu yüzden herhangi bir cevap en iyi şekilde özet olacaktır. Sorunuza dayanarak yapmaya değer olduğunu düşündüğüm önemli noktalardan bazıları. Kapsamlı bir liste değil.

İstisnaların her yere yakalanmaması amaçlanmıştır.

Ana döngüde genel bir istisna işleyicisi olduğu sürece - uygulamanın türüne bağlı olarak (web sunucusu, yerel servis, komut satırı yardımcı programı ...) - genellikle ihtiyacınız olan tüm özel durum işleyicileri vardır.

Kodumda, ana döngünün dışında sadece birkaç tane yakalama cümlesi var (eğer varsa). Ve bu modern C ++ 'da ortak yaklaşım gibi görünüyor.

İstisnalar ve iade kodları karşılıklı olarak dışlanmaz.

Bunu bir ya hep ya hiç yaklaşımı yapmamalısınız. İstisnai durumlar için istisnalar kullanılmalıdır. "Config dosyası bulunamadı", "Disk Dolu" veya yerel olarak kullanılamayacak herhangi bir şey.

Kullanıcı tarafından sağlanan bir dosya adının geçerli olup olmadığını kontrol etmek gibi yaygın hatalar, istisnalar için bir kullanım örneği değildir; Bunun yerine bu durumlarda bir dönüş değeri kullanın.

Yukarıdaki örneklerden gördüğünüz gibi, "dosya bulunamadı" kullanım durumuna bağlı olarak bir istisna veya dönüş kodu olabilir: "kurulumun bir parçasıdır" karşı "kullanıcı yazım hatası yapabilir".

Yani mutlak bir kural yoktur. Kaba bir kılavuz: yerel olarak ele alınabiliyorsa, onu bir geri dönüş değeri yapın; Yerel olarak idare edemiyorsanız, bir istisna atın.

İstisnaların statik kontrolü uygun değildir.

İstisnalar yine de yerel olarak ele alınmadığından, hangi istisnaların atılabileceği genellikle önemli değildir. Tek yararlı bilgi, herhangi bir istisnanın atılıp atılamayacağıdır.

Java'nın statik denetimi vardır, ancak genellikle başarısız bir deneme olarak kabul edilir ve çoğu dilde - özellikle C # - bu tür statik denetim olmadığından. Bu C # neden yok nedenleri hakkında iyi bir okuma .

Bu nedenlerden dolayı, C ++ throw(exceptionA, exceptionB)lehine itirazda bulundu noexcept(true). Varsayılan, bir fonksiyonun atabileceğidir, bu nedenle programcılar, belgeler açıkça belirtilmediği sürece bunu beklemelidir.

İstisna güvenli kodunu yazmak, istisna işleyicileri yazmakla hiçbir ilgisi yoktur.

İstisna güvenli kod yazmanın tamamen istisna işleyicileri yazmaktan nasıl kaçınılması gerektiğini söylerdim!

En iyi uygulamaların çoğu istisna işleyicilerinin sayısını azaltmayı amaçlamaktadır. Bir kez kod yazıp otomatik olarak çağırmak - örneğin RAII aracılığıyla - aynı kodu her yere kopyalayıp yapıştırmaktan daha az hatayla sonuçlanır.

C ++ programcıları istisna spesifikasyonlarını aramazlar. İstisna garantileri ararlar.

Bir kod parçasının bir istisna attığını varsayalım. Programcı bunun hala geçerli olacağını hangi varsayımlarla yapabilir? Kodun yazıldığı şekliyle kod, bir istisna sonrasında ne garanti ediyor?

Veya, belirli bir kod parçasının asla atılmamasını garanti edebileceği (yani, işletim sistemi işleminden başka hiçbir şeyin sonlandırılmadığı) mümkün mü?

İstisnalarla ilgili tartışmalarda "geri alma" kelimesi sıklıkla ortaya çıkıyor. Geçerli bir duruma (açıkça belgelenmiştir) geri dönebilmek bir istisna garantisi örneğidir. İstisna garantisi yoksa, bir program derhal sona ermelidir, çünkü daha sonra çalıştırılan herhangi bir kodun amaçlandığı gibi çalışacağı garanti edilmez - örneğin, eğer bellek bozulursa, başka bir işlem teknik olarak tanımsız davranıştır.

Çeşitli C ++ programlama teknikleri istisna garantileri sunar. RAII (kapsam tabanlı kaynak yönetimi), temizleme kodunu yürütmek ve kaynakların hem normal durumlarda hem de istisnai durumlarda serbest bırakılmasını sağlamak için bir mekanizma sağlar. Nesnelerde değişiklik yapmadan önce verilerin bir kopyasını almak, işlemin başarısız olması durumunda kişinin bu nesnenin durumunu geri yüklemesine izin verir. Ve bunun gibi.

Bu StackOverflow sorusuna verilen cevaplar, C ++ programcılarının kodlarında olabilecek tüm olası arıza modlarını anlamaya ve başarısızlıklarına rağmen program durumunun geçerliliğini korumaya çalışmasına büyük ölçüde bir fikir verir. C ++ kodunun satır bazında analizi alışkanlık haline gelir.

C ++ 'da (üretim kullanımı için) geliştirilirken, detaylardan bahsedemezsiniz. Ayrıca, ikili blob (açık kaynaklı olmayan) C ++ programcılarının ağzıdır. İkili blob çağırmam gerekiyorsa ve blob başarısız olursa, o zaman tersine mühendislik C ++ programcısının yapacağı şeydir.

Referans: http://en.cppreference.com/w/cpp/language/exceptions#Exception_safety - İstisna Güvenliği bölümüne bakın.

C ++ istisna spesifikasyonlarını uygulamada başarısız oldu. Diğer dillerde daha sonra yapılan analizler istisna şartnamelerinin pratik olmadığını söylüyor.

Neden başarısız bir girişim: kesinlikle zorla uygulamak için tip sisteminin bir parçası olmak zorunda. Ama öyle değil. Derleyici özel durum belirtimi için denetleme yapmaz.

Neden C ++ bunu seçti ve neden diğer dillerden (Java) elde edilen deneyimler istisna şartnamesinin suçlu olduğunu kanıtladı: Birinin bir işlevinin uygulanmasını değiştirdiği gibi (örneğin, yeni bir tür atabilecek başka bir işlevi çağırması gerekir) istisna), katı bir istisna şartname uygulaması, bu şartnameyi de güncellemeniz gerektiği anlamına gelir. Bu yayılır - basit bir değişiklik olan düzinelerce veya yüzlerce fonksiyon için istisna şartnamesini güncellemeniz gerekebilir. Soyut temel sınıflar için (işlerin C ++ eşdeğeri) durumları kötüye gider. Arayüzlerde istisna şartnamesi uygulanırsa, arayüz uygulamalarının farklı istisna türleri atan fonksiyonları çağırmasına izin verilmez.

Referans: http://www.gotw.ca/publications/mill22.htm

C ++ 17 ile başlayarak, [[nodiscard]]öznitelik, işlev dönüş değerlerinde kullanılabilir (bkz. Https://stackoverflow.com/questions/39327028/can-ac-function-be-declared-such-that-the-return-value göz ardı edilemez .

Öyleyse, bir kod değişikliği yaparsam ve bu yeni bir tür arıza koşulu ortaya çıkarırsa (örneğin yeni bir istisna türü), bu bir değişiklik mi? Arayan kişiyi kodu güncellemeye mi zorlamalıydı yoksa en azından değişiklik konusunda uyarılmalı mıydı?

C ++ programcılarının istisna spesifikasyonları yerine istisna garantileri aradığı argümanlarını kabul ederseniz, cevap, yeni tür bir arıza koşulu istisnaların hiçbirini bozmazsa, daha önce vaat ettiğiniz kodu garanti etmez, bunun kesin bir değişiklik olmadığıdır.

C () işlevini çağıran bir geliştirici düşünün. Belgeleri kontrol etmiyor, bu yüzden istisnalar yakalamıyor. Çağrı güvenli değil

Tamamen güvenli. Her yerdeki istisnaları yakalaması gerekmiyor, sadece gerçekten yararlı bir şeyler yapabileceği bir yerde deneyebilir / deneyebilir. Sadece diş ipinden sızmasına izin veriyorsa güvenli değildir, ancak bunun olmasını önlemek genellikle zor değildir.

Kritik bir sistem inşa ediyorsanız, takım liderinizin tavsiyelerine uymayı ve istisnalar kullanmamayı düşünün. Bu Lockheed Martin'in Ortak Vurucu Avcı Uçağı C ++ Kodlama Standartlarındaki AV Kuralı 208'dir . Öte yandan, MISRA C ++ yönergelerinin, bir MISRA uyumlu yazılım sistemi oluştururken istisnaların ne zaman kullanılabileceği ve kullanılamayacağına ilişkin çok özel kuralları vardır.

Kritik sistemler inşa ediyorsanız, olasılıklar statik analiz araçlarını da çalıştırıyor olmanızdır. Birçok statik analiz aracı, bir yöntemin dönüş değerini kontrol etmezseniz, hata işleme durumlarının kolayca ortaya çıkması durumunda sizi uyaracaktır. Bildiğim kadarıyla, uygun istisnaların ele alınmasının tespiti için benzer araç desteği o kadar güçlü değil.

Nihayetinde, sözleşmenin ve savunma programlamasının tasarımın statik analizle birleştiğinde, kritik yazılım sistemleri için istisnalardan daha güvenli olduğunu savunuyorum .