一般都不用寫的，有些確實要寫，比如StrToInt,如果引數是空的系統會報錯。所以程式自己處理就不會彈出錯誤。

考慮程式如何正確執行不需要太多時間。程式設計師的大部分時間是在考慮處理異常，即使這樣，程式在實際使用過程中還會遇到很多你想不到的情況。所以儘可能的在程式碼中處理異常，加入防守程式碼，程式才能穩定，你的水平才會提高

如果你的程式碼也就百行，幾千行，幾個人開發，不寫，雖有影響，但整體可控，出問題了一行行找也不難。但是如果幾百人開發的，幾百萬行的程式碼，你就知道異常處理的價值了。

看情況了，如果只是寫個小demo，小玩具，是可以不寫的。但如果是正兒八經的程式碼，理論上來說是一定要的。可是沒有人能保證每個異常都能用程式碼覆蓋到，bug是改不完的。所以我們也不較真地要求自己每個異常都處理，根據自己的經驗和對業務的理解，挑重點的地方處理。處理得越多，程式碼魯棒性越好。怎麼挑是對程式設計師的程式碼能力的考驗，我們既要在一定時間內完成需求，又要保證程式碼的質量。

在C語言程式開發中，呼叫一個有返回值的函式時，一般要對函式的返回值做判斷，以確定函式是否按照預期執行。如果被呼叫函式沒有按照預期執行，最好加上相應的錯誤處理程式碼，否則最終編譯得到的C語言程式穩定性就不夠好，遇到一點點意外，可能就不會正常工作了。

沒有判斷C語言函式的返回值，會有什麼問題？

例如下面這段C語言程式：

上面這段C語言程式首先定義了一個 buf 並且把它清零，程式設計師的本意是在 something 檔案裡存放一串字串，並且透過 read() 函式將其讀出，然後列印到控制檯。

但是，可能因為某種原因，something 檔案沒有生成，那麼上面這段C語言程式碼編譯得到的程式就什麼也不會輸出了。遇到這種什麼都沒有輸出的情況，初學者甚至可能會以為程式沒有執行。

要是這段C語言程式碼隱藏在一個比較大的專案間，something 檔案是由其他邏輯生成的，這時要定位問題程式碼可能就要花些功夫了。

再看一個例子，相關C語言程式碼如下：

可以看出，程式設計師的本意是申請一塊記憶體，並且讓 buf 指向它，然後在 buf 中存放一段字串並輸出到控制檯。然而，這段程式碼隱藏著一個比較嚴重的隱患——malloc() 是有可能失敗的。如果 malloc() 函式執行失敗，buf 會指向 NULL，此時 sprintf() 函式就會操作空指標，引發段錯誤(Segmentation fault)。

C語言程式中的“段錯誤”出現時，通常不會有其他錯誤提示資訊，這對於除錯來說是比較難受的。不過在 Linux 中可以設定 core dumped，利用 gdb 等工具排查。不管如何，“段錯誤”都是相對來說比較難定位的錯誤。

所以，在編寫C語言程式時，判斷函式的返回值非常重要。透過返回值，我們能夠知道函式有沒有正常執行，如果它沒有正常執行，就做相應的錯誤處理，只有這樣，最終得到的C語言程式才能應對各種意外。

現在將上面兩段 C語言程式碼改寫——增加返回值判斷邏輯：

上面的C語言程式碼在可能會出錯的地方做了判斷，並且編寫了額外的錯誤處理程式碼。在本例中，如果 malloc() 執行失敗，就向控制檯列印“malloc failed”以及錯誤原因，並且終止程式。open() 函式和 read() 函式也做了類似的錯誤處理。

這裡值得一提的一個小技巧是：Linux C語言程式設計中，很多函式執行失敗時，系統會將錯誤碼放入 errno。我們當然可以直接獲取 errno，將其轉換成錯誤字串也是可以的：

但是更方便的做法是藉助 printf() 函式提供的 “%m”，以下兩行C語言程式碼是等價的：

現在編譯上面的C語言程式碼並且執行，得到如下輸出：

這樣一來，就算C語言程式遇到“意外情況”，程式也不會反應都沒有。從這段輸出我們可以知道：open() 函式執行失敗了，原因是“No such file or directory（沒有這樣的檔案或者目錄）”。對於本例而言，這是因為當前目錄沒有 something 檔案。

請看下面的C語言程式碼：

可以說這段程式碼非常的“臃腫”和“囉嗦”，多個 if-else 堆疊在一起，讀起來比較難受。如果呼叫的函式再多一點，if-else 堆疊再多一點，程式碼的可讀性就更差了。所以，在實際C語言專案開發中，一般都不這麼寫。

之前的文章介紹過使用 do{}while(0) 將若干程式碼封裝成宏的技巧，其實 do{}while(0) 的作用還不止於此，請看下面的C語言程式碼：

上面的C語言程式藉助 break 語句，在遇到錯誤時，就直接跳出 do{}while 語句，可以看出，程式碼簡潔多了。不過仔細想想，這種方法還是有不方便的地方。請再看看上面這段C語言程式碼，應該能夠發現，close(fd); 和 free(buf); 語句都需要寫多次。如果呼叫的函式再多一些，需要重複寫的語句就更多了。這很不友好，也很不利於維護。

那該怎麼辦呢？

雖然很多人不提倡使用 goto 語句，但是它確實能夠很方便的處理錯誤，請看下面的C語言程式碼：

將錯誤處理語句統一放在最後處理，整個程式碼顯得非常簡潔，也非常易讀和維護。不過，這種寫法對變數的初值有一定的要求。

想想為什麼？