iptal mi, sonlandırmak mı yoksa çıkmak mı?

Bu üçü arasındaki fark nedir ve düzgün bir şekilde idare edemediğim bir istisna durumunda programı nasıl sonlandırabilirim?

Benim tavsiyem bunların hiçbirini kullanmamaktır. Bunun yerine, oradan ve basitçe catchbaşa çıkamayacağınız istisnalar . Bu, yığın çözme işleminin doğru şekilde gerçekleşeceği ve tüm yıkıcıların çağrıldığı garanti edildiği anlamına gelir. Diğer bir deyişle:main()return

int main() {
    try {
       // your stuff
    }
    catch( ... ) {
       return 1;    // or whatever
    }
}

• abort , programın "anormal" sonunu gösterir ve POSIX sinyalini SIGABRT yükseltir; bu, bu sinyal için kaydettiğiniz herhangi bir işleyicinin çalıştırılacağı anlamına gelir, ancak program her iki durumda da son kelimeleri sonlandıracaktır. Genellikle abortbir C programında, hatanın hatalı girdi veya ağ arızası gibi bir şeyden ziyade programdaki bir hata olma olasılığı bulunan beklenmedik bir hata durumundan çıkmak için kullanırsınız . Örneğin, abortmantıksal olarak hiçbir zaman gerçekleşmemesi gereken bir veri yapısının içinde bir NULL işaretçisi olduğu tespit edilirse bu olabilir.

• exit , programın "normal" bir sonunu belirtir, ancak bu yine de bir hata olduğunu gösterebilir (ancak bir hata değildir). Başka bir deyişle, exitkullanıcı ayrıştırılamayan girdi verdiyse veya bir dosya okunamadıysa bir hata koduyla karşılaşabilirsiniz. 0 çıkış kodu, başarıyı gösterir. exitayrıca isteğe bağlı olarak işleyicileri programı bitirmeden önce çağırır. Bunlar atexitve on_exitişlevlerine kaydedilir.

• std :: terminate , işlenmemiş bir istisna olduğunda bir C ++ programında otomatik olarak çağrılan şeydir. Bu, abortistisnalar atarak tüm istisnai hatalarınızı rapor ettiğinizi varsayarsak , esasen C ++ ile eşdeğerdir . Bu std::set_terminate, varsayılan olarak basitçe çağıran işlev tarafından ayarlanan bir işleyiciyi çağırır abort.

C ++ 'da, genellikle arama yapmaktan abortveya exithatadan kaçınmak istersiniz , çünkü bir istisna atmak ve programın sonlandırılıp sonlandırılmayacağına kodun çağrı yığınının ilerlemesine izin vermesine izin vermek daha iyidir. exitBaşarı için kullanıp kullanmamanız bir durum meselesidir - programı içindeki return ifadesinden başka bir yerde sonlandırmanın mantıklı olup olmadığına bakılmaksızın main.

std::terminateC ++ 'da bile son bir hata raporlama aracı olarak düşünülmelidir. Sorun std::terminateyok işleyicisi sonlandırmak olduğunu değil işlenmeyen gitti istisna erişebilir, böylece ne olduğunu anlatmak için bir yolu yoktur. Genelde main'in tamamını bir try { } catch (std::exception& ex) { }blokta sarmalamanız çok daha iyidir . En azından o zaman istisnalardan türetilen istisnalar hakkında daha fazla bilgi bildirebilirsiniz std::exception(elbette kaynaklanmayan istisnalar std::exceptionyine de ele alınmayacaktır ).

Gövdesini tamamlayan mainiçinde try { } catch(...) { }çok daha iyi tekrar söz konusu istisna erişimi yok çünkü, işleyici sonlandırmak ayarı daha değil. Düzenleme: Neil Butterworth'un cevabına göre, bu durumda yığının çözülmesinin bir yararı var, bu (biraz şaşırtıcı bir şekilde) işlenmemiş bir istisna için doğru değil.

std :: abort ve std :: exit (ve daha fazlası: std :: _ Exit, std :: quick_exit) sadece daha düşük seviyeli fonksiyonlardır. Bunları programa tam olarak ne yapmasını istediğinizi söylemek için kullanırsınız: hangi yıkıcıları (ve eğer) çağırmalı, başka hangi temizleme işlevlerini çağırmalı, hangi değeri döndürmeli vb.

std :: terminate daha yüksek seviyeli bir soyutlamadır: programda bir hata oluştuğunu ve herhangi bir nedenle bir istisna atarak işlemenin mümkün olmadığını belirtmek için (çalışma zamanı veya siz tarafından) çağrılır. Bunun gerekliliği, genellikle istisna mekanizmasının kendisinde hata oluştuğunda ortaya çıkar, ancak programınızın verilen hatanın ötesinde devam etmesini istemediğinizde bunu istediğiniz zaman kullanabilirsiniz. Std :: denir sonlandırmak zaman durumların tam listesini derlenmiş benim sonrası. Std :: terminate'in ne yapacağı belirtilmemiştir, çünkü onun kontrolü sizdedir. Herhangi bir işlevi kaydederek davranışı yapılandırabilirsiniz. Sahip olduğunuz sınırlamalar, işlevin hata sitesine geri dönememesi ve bir istisna yoluyla çıkamamasıdır, ancak teknik olarak mesaj pompanızı içeriden başlatabilirsiniz. İçeride yapabileceğiniz yararlı şeylerin listesi için diğer yazıma bakın .

Özellikle, std :: terminate'in, ele alınamayan atılan bir istisna nedeniyle std :: terminate çağrıldığı bağlamlarda bir istisna işleyicisi olarak kabul edildiğini ve istisnanın ne olduğunu kontrol edip C ++ kullanarak inceleyebileceğinizi unutmayın. 11 std :: rethrow_exception ve std :: current_exception kullanarak. Hepsi benim yazımda .

quick_exit () !

Programınız çok iş parçacıklıysa, çağrı exit()büyük olasılıkla bir çökmeye neden olacaktır çünkü global / statik std::threadnesneler iş parçacıklarından çıkmadan yok edilmeye çalışılacaktır.

Bir hata kodu döndürmek ve programdan normal şekilde (aşağı yukarı) çıkmak istiyorsanız quick_exit(), çok iş parçacıklı programları çağırın . Anormal sonlandırma için (hata kodunu belirleme olanağınız olmadan) abort()veya std::terminate()çağrılabilir.

Not: quick_exit (), 2015 sürümüne kadar MSVC ++ tarafından desteklenmiyordu .

• terminate, çağrıldığında ne olacağını kaydetme olanağını size bırakır. Diğer ikisinden biri olmalı.
• çıkış, bir çıkış durumunu belirlemeye izin veren normal bir çıkıştır. At_exit () tarafından kaydedilen işleyiciler çalıştırılır
• iptal anormal bir çıkıştır. Çalıştırılan tek şey SIGABRT için sinyal işleyicidir.

• terminate (), işlenemeyen bir istisna meydana geldiğinde otomatik olarak çağrılır. Varsayılan olarak, abort () çağrılarını sonlandırın (). Set_terminate () işlevi ile özel bir tutamaç ayarlayabilirsiniz.

  abort () SIGABRT sinyalini gönderir.

  exit () mutlaka kötü bir şey değildir. Uygulamadan başarıyla çıkar ve atexit () işlevlerini LIFO sırasında çağırır. Bunu normalde C ++ uygulamalarında görmüyorum, ancak sonunda bir çıkış kodu gönderdiği birçok unix tabanlı uygulamada görüyorum. Genellikle bir çıkış (0), uygulamanın başarılı bir şekilde çalıştırıldığını gösterir.