1樓：
C++的異常就好比一瓶水，純淨的水它不導電。
但是你在幾乎所有地方，都得預設水是導體，這就是現實。如果你想用水做絕緣體，那必須在工程的所有地方避免導電離子的引入，包括容器，管道，操作人員，特別是當你把整個專案包裝成產品給他人使用時。
2樓：ll hgyxb
我覺得異常還是需要的, 但是應該在碰到無法處理的錯誤或無法通過返回值來表示錯誤時丟擲,此時應該假設程式會終止.
另一種用法是只在乙個函式內使用,不要跑到外部.
3樓：
出錯要掛的時候，拋異常，例如庫的使用者傳了個null做引數，拋個異常，告訴使用者不！許！傳！null！，這個用法就是不正確，我不處理了，選擇狗帶。
4樓：
雖然使用C++這麼久，但是對於異常這東西確實整不明白，所以乾脆當鴕鳥，採取「不丟擲，不捕獲」的態度。我的程式不會主動丟擲異常；內部呼叫的函式如果丟擲了異常，我也不管。當然，這個也有例外，就是有些庫里，基本上就是把異常當成錯誤碼來用了，動不動就會丟擲個異常，如果我知道哪個異常是什麼意思，可能會捕獲一下，轉成錯誤碼來返回；其它的就不管了。
catch (...) 這種事不能幹，自己不認識的異常還敢胡亂吃，小心中毒。
5樓：楊明陽
How can I handle a constructor that fails?
How should I handle resources if my constructors may throw exceptions?
Standard C++
說到底還是RAII
6樓：白紙無字Zonciu
我對異常的理解是有不在設計邏輯中的錯誤發生，比如連線中斷，可能是網路波動，可能是客戶端意外關閉，甚至可能物理網路故障，比如檔案讀寫異常，可能是檔案損壞，可能是物理壞道等等，不一而足（對那個因為醫院裝置輻射導致計算機資料異常那個故事印象深刻）。對於程式邏輯來說，意外情況數不勝數，不可能給所有狀態都打乙個特定的error code返回來，而且有的異常是可以釋放當前資源，然後重試的，有的是無法進行只能結束程式的。
我一般是在可恢復部分用try-catch包裹，發生致命性異常的話就直接扔到最頂層報告錯誤，退出。
7樓：碧水溪風
***;
if(***)return ***;
***;
if(***)return ***;
***;
if(***)return ***;
***;
if(***)return ***;
………***;
if(***)goto ***;
***;
if(***)goto ***;
***;
if(***)goto ***;
***;
if(***)goto ***;
return;
***:
………你們自己選吧
8樓：Star.E
異常的使用應該關注資源，而不是狀態。
異常與其說是匯報錯誤的發生，不如說是用來回退呼叫堆疊的，要配合RAII使用。
一般用於資源獲取失敗時，一路向上釋放資源，直至程式資源正常為止。
程式很多異常狀態是邏輯上的問題，異常可以處理，但不是唯一選擇，也不是最好選擇。
比如邏輯上一定成立的，應該用assert檢查，然後用測試例子覆蓋所有輸入，而不是亂拋異常。
邏輯上可能不成立的，應該用返回值處理，而不是拋異常。因為異常能處理的邏輯實際上只有乙個，就是出錯了向上回退釋放資源。而依靠返回值能處理的邏輯更廣。
可以參考boost asio的設計，乙個函式提供兩個介面，返回error_code的和拋異常的。返回error_code的適合即時解決問題，拋異常的適合自己不處理交由別人解決。
邏輯複雜的可以用狀態機管理，比如boost meta state machine。用異常或者error_code管理屬於手上有榔頭看什麼都是釘子。
異常用的比較多的有建構函式，比如建立乙個物件，需要依賴檔案、網路、資料庫等。如果有乙個步驟出問題，那麼物件建立失敗，這時就應該拋異常釋放已有資源。你也可以選擇多步init初始化然後根據返回值判斷，但這很羅嗦，把負擔轉移到使用者身上了。
而異常從設計上就是用來簡化這一步驟的，使得建構函式具有一定原子性，簡單、統一。
還有就是向上跳出邏輯、迴圈、中斷執行緒等，這種屬於資源不再需要、用拋異常簡化資源釋放的情況。
關於什麼時候應該catch的話，一般是資源的獲取（物件建立，函式呼叫、各種容器的.at()）可能會失敗，且需要處理的時候。這種catch寫哪個層面、粒度粗細、是需要衡量的，沒有定數。
還有就是在析構函式裡要catch所有異常，比如在析構函式裡打log也可能拋異常，這個異常不應該跑出析構函式的範圍。這是因為c++ RAII的「公理"是資源釋放一定會成功，拋異常就進入不可名狀之狀態了
9樓：
C++中的異常是必不可少的！如果說因為異常導致結構複雜，那沒有異常就簡直是災難。假設沒有異常的情況
template
T>void foo( constT& t)難道要C ++教科書裡寫乙個教條，所有型別必須定義乙個名叫check ()判斷這個物件是否正確的方法？ (那麼問題來了， copy -construction都錯了 ，怎麼能保證 check ()不錯?) 其實一些人提到在建構函式裡加乙個引數判斷是否構造成功，如果這作為一種手法，就跟這「教條」一樣愚蠢，因為這招式太愚蠢了 另外異常確實會降低設計的難度。例如 void foo() //異常中立 如果沒有異常 error_code foo() 然後你在定義error_code的時候 enum error_code 看到這兩個例子，你們是不是覺得應該全面鋪開使用異常呢？ 10樓：藍色 很雞肋的東西，是唯一編譯器前端完全掌控，編譯器後端看不到的東西。 我個人不推崇C++ Exception，我覺得這算是乙個語言發展走的彎路。 11樓： c++難道一般情況下不是要避免raw pointer嗎？為什麼所有人都在說異常引起洩露？除非非常需要效能的時候，這時難道不是直接禁止異常嗎？ 12樓： 目前自己就在處理這個可惡的異常，合併了乙個C語言寫的專案與乙個C++寫的專案，呼叫棧裡面上層基本是C，呼叫C++完成一些操作，被逼無耐只能使用C++丟擲異常，然後catch住，轉百錯誤碼返回。最近才開始使用C++，感覺它是乙個最靈活但是最多陷阱的語言，適合高手使用，而不適合作為第一門程式語言學習和使用。 epcastle 使用異常，只是為了表達乙個使用場景裡，這樣做是有錯的，我要警告你，禁止你。比如，中國象棋裡，未過河的兵左右後退走，錯，拋異常。所以乙個場景裡使用一兩個異常就好，可以定義規則異常，出錯了，在異常訊息寫對應的話，比如，你使用的物件兵，不能這麼這麼走。關鍵字 場景錯誤 何曉陽 這個從程式... 我的建議是，在 main 裡面做個異常處理，捕獲 bad alloc，該寫日誌就寫日誌，該發郵件就發郵件 記得用另外乙個程式 然後讓他掛掉。 Glavo 如果沒有辦法 new 了，說明你的程式基本上沒救了，也沒必要去 catch 下來處理。想要做什麼收尾工作就用 std set terminate ... 黃亮anthony 在main中增加乙個catch子句就可以得到你想要的結果。intmain catch return0 輸出A constructor.B constructor.C constructor.D constructor.C destructor.B destructor. XZia...什麼情況下使用異常處理？
C 每次 new 都需要做異常處理嗎？
C 如何寫出異常安全的建構函式？