這種情況應該中途就返回，寫成
很多人避免中途返回，是因為後面需要釋放已經分配的資源。在 C++ 中，應該一旦分配資源，就立即使用 RAII 或者 ScopeGuard 來自動清理。比如
或者
這樣的寫法，可以保證資源永遠都會被釋放。就可以放心地中途退出。這種寫法也使得重構程式碼更容易，可以將資源分配和釋放的程式碼一起移動，因為它們是靠在一起的。
那些使用 goto, 或者 while (true) break 的，可以緩解一部分問題。但在C++中，沒有ScopeGuard 通用和優雅。
我很希望C++可以定義出一個類似 Go 語言或者 Swift 語言的 defer 特性，或者將 ScopeGuard 新增到標準庫中。這樣就不用不同專案各自實現風格各異的 ScopeGuard 了。
----------------
我個人是不喜歡異常 exception 的。以往我一直覺得異常是很好的特性，但現在覺得異常並非一定是好的。異常的問題在於發生異常的地方與處理異常的地方分離開來，真正處理的時候難以收集到足夠的資訊。異常也容易濫用，很容易只丟擲異常而不處理，或者乾脆在最外層接收所有異常，再打印出異常資訊。這樣的話，也就失去了異常處理的意義。
用錯誤碼雖然看起來死板麻煩，但會是可控的。
有些人會說，構造函數出現錯誤怎麼辦，那時沒有返回值，也就沒有錯誤碼。這種情況下，只要簡單讓建構函式不會出現錯誤就行了，建構函式會出現錯誤，是因為在裡面做太多事情了。比如我就不會在建構函式中開啟檔案，而是提供 open 或者 init 的成員函式，在裡面開啟。
再來說說使用錯誤碼的介面設計。這樣設計介面很常見：
doSomething 透過錯誤碼來判斷錯誤。但因為有很多函式會返回 bool 或者指標來表示對錯，絕大多數非 0 表示成功。上面那種函式介面設計，會容易將函式誤用成：
包含錯誤碼的介面應該設計成
但需要簡單判斷對錯，就這樣使用
但需要考慮更詳細的錯誤資訊，就這樣呼叫
這種情況應該中途就返回，寫成
很多人避免中途返回，是因為後面需要釋放已經分配的資源。在 C++ 中，應該一旦分配資源，就立即使用 RAII 或者 ScopeGuard 來自動清理。比如
或者
這樣的寫法，可以保證資源永遠都會被釋放。就可以放心地中途退出。這種寫法也使得重構程式碼更容易，可以將資源分配和釋放的程式碼一起移動，因為它們是靠在一起的。
那些使用 goto, 或者 while (true) break 的，可以緩解一部分問題。但在C++中，沒有ScopeGuard 通用和優雅。
我很希望C++可以定義出一個類似 Go 語言或者 Swift 語言的 defer 特性，或者將 ScopeGuard 新增到標準庫中。這樣就不用不同專案各自實現風格各異的 ScopeGuard 了。
關於 ScopeGuard 更詳細的內容，參考這篇文章 ScopeGuard 介紹和實現 - 黃二少碎碎念 - 知乎專欄----------------
我個人是不喜歡異常 exception 的。以往我一直覺得異常是很好的特性，但現在覺得異常並非一定是好的。異常的問題在於發生異常的地方與處理異常的地方分離開來，真正處理的時候難以收集到足夠的資訊。異常也容易濫用，很容易只丟擲異常而不處理，或者乾脆在最外層接收所有異常，再打印出異常資訊。這樣的話，也就失去了異常處理的意義。
用錯誤碼雖然看起來死板麻煩，但會是可控的。
有些人會說，構造函數出現錯誤怎麼辦，那時沒有返回值，也就沒有錯誤碼。這種情況下，只要簡單讓建構函式不會出現錯誤就行了，建構函式會出現錯誤，是因為在裡面做太多事情了。比如我就不會在建構函式中開啟檔案，而是提供 open 或者 init 的成員函式，在裡面開啟。
----------------
再來說說使用錯誤碼的介面設計。這樣設計介面很常見：
doSomething 透過錯誤碼來判斷錯誤。但因為有很多函式會返回 bool 或者指標來表示對錯，絕大多數非 0 表示成功。上面那種函式介面設計，會容易將函式誤用成：
包含錯誤碼的介面應該設計成
但需要簡單判斷對錯，就這樣使用
但需要考慮更詳細的錯誤資訊，就這樣呼叫