異常不可用於邏輯處理

異常是錯誤處理，但是不可以用於邏輯處理，假設我們封裝了乙個msgqueue,這個類負責收集由服務端一條接受執行緒收集客戶端訊息，另一條工作執行緒負責取出訊息，並對訊息進行處理。

class msg ;
class msgqueue

這裡定義了msgqueue的兩個方式，分別是收集客戶端訊息，然後儲存訊息的put方法，還有處理客戶端訊息，取出客戶訊息的get方法。

對於put方法，由於記憶體有限，我們不可能讓這個msgqueue無限度的儲存訊息，所以當儲存的訊息過多，無法再儲存客戶端訊息時，我們丟擲std::length_error異常。

對於get方法，假設queue裡沒有任何元素了，我們要告訴呼叫者queue是空的，但是這裡無法返回乙個空元素，所以我們的做法就是丟擲乙個std::out_of_range(stl的queue當queue是空時，呼叫front()方法居然可以取出元素，不丟擲任何異常)。

工作執行緒的部分**如下:

msg msg;
while (true) catch (std::out_of_range) 
}

msgqueue由工作執行緒和工作執行緒共享，工作執行緒不斷輪詢，嘗試msgqueue是否可以取出訊息，不可以表示沒有新的訊息的到來，就等待一秒，可以取出訊息就進行處理。

這段**的問題在於把異常用於邏輯處理了，msgqueue為空，這個場景是正常場景，因為不可能每個時刻都有訊息過來，異常是用於錯誤處理的，所以合適的做法我們是應該先判斷msgqueue是否為空，不為空，我們才呼叫msgqueue.get()取出訊息。

class msgqueue

新增判斷queue是否為空的成員函式後，工作執行緒的**修改如下:

msg msg;
while (true) 
msg = msgqueue.get(); //
取出客戶端訊息 
handle(msg); //
處理客戶端訊息 
}

這樣**就簡潔明瞭很多，沒有像try {} catch{}導致成塊**的出現，尤其是層次一多，**很難一目了然。

作為msgqueue不僅要考慮呼叫者各個呼叫場景，應該提供判斷isempty()之類的方法，避免呼叫者在做邏輯處理時，不得去用異常捕獲，寫出一些難以理解的**。

當區域性的控制可以滿足我們的業務時，就不要使用異常處理了，請用異常做錯誤處理。

異常適用於哪些錯誤處理呢，**我需要try {} catch{}呢，例如網路異常，檔案io異常這些典型的錯誤，從乙個伺服器中，讀取伺服器的響應，可能會出現網路中斷,這樣的處理**是合適使用try {} catch{}處理的。

try   catch (networkerror)

例如像檔案io，我們讀寫的過程中，如果真的那麼倒霉，遇到硬碟壞道，也必須做處理，乙個健壯的程式是要考慮任何能想到的錯誤的

try   catch (io_error)

這些都是錯誤處理，是使用異常try {} catch{}的場景,看**人的一看就知道try{}裡的**可能會發生錯誤,出現錯誤是非法場景,但是又不能完全避免。

try{} catch{}這些錯誤處理語句，能少用就少用，**成塊出現，很容易讓**變得難以閱讀，如果你用異常來做邏輯處理，****現try{} catch{}的概率會大大提高，導致**可閱讀性很差。

例如當if else的**塊有三層以上

if (...) }}
}

這樣的**閱讀性很差(還沒有加else,否則更暈)，if的層次超過了3層，我就覺得**該重構了，因為我覺得就算是這段**的開發者，過了乙個星期後，要看看這段**，重新梳理邏輯，至少要乙個多小時，如果你重構了，你只需要十分鐘就可以看懂**邏輯了(題外話了)

使用try {} catch {}會導致**塊的層次增加，**可閱讀性變差，公認的做法是用來做錯誤處理，如果用來做邏輯處理，會帶來沒有必要的麻煩，請盡量避免使用。