使用錯誤返回碼進行參數驗證是否被認為是好的做法？我的意思是有人應該在哪里使用錯誤與恐慌（是否有任何指導方針？）。例如：檢查非零+如果它是零則返回錯誤是一個好習慣嗎？或檢查正確的整數范圍等。我想，使用錯誤通常會讓 Go 感覺非常 C-ish 并且看起來很糟糕。在這些情況下，恐慌是一個很好的選擇嗎？或者 Gopher 應該使用 Python/Ruby/JS 方法“讓它失敗”？我有點困惑，因為恐慌是我理解中真正的“錯誤”。但是一直使用錯誤是不好的。即使我會返回錯誤代碼：如果有人將錯誤的參數傳遞給我的函數但忽略了錯誤代碼，我該怎么辦？-> 沒什么！所以老實說，我會說恐慌對那些情況很好，但在錯誤代碼用于恐慌的語言中，這不是很清楚。
2 回答
哆啦的時光機
TA貢獻1779條經驗 獲得超6個贊
Go 中的"Escaping" panics 1（我的意思是，那些可能由構成包的公共 API 的函數產生的）是用來處理程序員所做的錯誤。因此，如果您的函數獲得一個指向對象的指針，并且這不能nil（例如，指示該值丟失），則繼續并取消引用該指針以使運行時panic本身（如果它恰好是nil. 如果一個函數需要一個必須在某個范圍內的整數，panic如果它不在那個范圍內——因為在一個正確的程序中，所有可能傳遞給你的函數的值都是 在那個范圍內，如果他們不這樣做，那么要么程序員沒有遵守 API，要么他們沒有清理從外部獲取的值，這又不是你的錯。
在另一方面，如故障問題打開一個文件或pefrorm你的函數應該執行一些其他動作正確調用時應該不會引起panicS和函數返回一個適當的錯誤信息。
請注意，null在 .NET 和 Java 代碼中對公共 API 函數中的參數進行顯式檢查的建議具有不同的目標，即使此類錯誤更具可讀性。但是由于 99% 的 .NET 和 Java 代碼只是讓所有異常傳播到頂層（然后顯示或可能被記錄），因此它只是用另一個替換一個（由運行時生成的）異常。這可能會使錯誤更加明顯——在 API 函數中執行失敗，而不是在調用堆棧更深處的某個地方——但會為這些 API 函數增加不必要的麻煩。所以是的，這是自以為是，但我的主觀意見是：在 Go 中讓它崩潰是可以的——你會得到一個描述性的堆棧跟蹤。
TL; 博士
關于運行時問題的處理，
panics 用于編程錯誤；返回錯誤是針對執行預期功能任務的問題。
1panic s 的另一個合法用途是從深度遞歸處理/計算返回的快速“冷路徑”；在這種情況下，panic應該由您的包捕獲和處理，并且相應的公共 API 函數應該返回錯誤。有關更多信息，請參閱此和此。
- 2 回答
- 0 關注
- 217 瀏覽
添加回答
舉報
0/150
提交
取消