這種情況應該中途就返回,寫成
很多人避免中途返回,是因為後面需要釋放已經分配的資源。在 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 表示成功。上面那種函式介面設計,會容易將函式誤用成:
包含錯誤碼的介面應該設計成
但需要簡單判斷對錯,就這樣使用
但需要考慮更詳細的錯誤資訊,就這樣呼叫