返回null或再次拋出異常

Question

我已經找到了這個問題的答案，我發現了以下建議：

如果您總是希望找到一個值，則拋出異常（如果缺少）。 例外意味着存在問題。 如果該值可能丟失或存在且兩者都對應用程序邏輯有效，則返回null。
如果確實是錯誤，則僅拋出異常。 如果對象的預期行為不存在，則返回null。

但是我應該如何在我的（如此隨意的）情況下解釋它們：我的網絡應用程序控制器正在接收顯示具有特定ID的用戶的詳細信息的請求。 Controller要求服務層獲取用戶，然后服務返回該對象（如果已找到）。 如果不是，則會發出重定向到“默認”位置。

當有人在請求URL中傳遞無效的用戶ID時，我該怎么辦？ 我應該將其視為“預期行為”並將null返回給控制器，或者我應該將其稱為“問題或意外行為”，從而在服務方法中拋出異常並捕獲控制器內部？

從技術上講，它畢竟不是一個很大的區別，但我希望通過遵循標准對流來做正確的方法。 在此先感謝您的任何建議。

編輯：我認為，應用程序生成的URL是有效的和現有的 - 當用戶點擊時，應該找到具有certaing id的用戶。 當用戶嘗試通過在瀏覽器的地址欄中手動鍵入URL來嘗試訪問具有錯誤（不存在）用戶ID的URL時，我想知道如何處理這種情況。

Answer 1

如果我理解正確，則包含用戶ID的請求來自客戶端（不受控制）。 應用您引用的經驗法則：無效的用戶輸入是一個完全可以預期的情況，它不需要異常，而是通過向客戶端返回適當的錯誤消息來優雅地處理空值。

（OTOH如果請求中的用戶ID是由另一個app /來自DB等自動生成的，則無效的用戶ID將是意外的，因此異常是合適的。）

Answer 2

我個人的建議是記錄錯誤詳細信息（IP地址，無效的用戶ID）並將用戶重定向到錯誤頁面，該錯誤頁面表示發生了一些錯誤並且已通知管理員。 點擊so-n-so鏈接返回主頁等。

指出，無論是拋出異常還是返回null ，只需確保最外面的過濾器或處理程序在將響應返回給用戶之前“記錄”詳細信息。

Answer 3

What should I do when someone passes invalid user id inside the request URL?

您有兩種選擇：顯示您提到的“默認”頁面或返回“未找到”/ 404。

關於null ，它取決於。 如果你認為null對於引用是不可接受的，那么用@NotNull注釋它，並且注釋應該在獲得空引用時處理正確的事情：即拋出（未經檢查的）異常（當然你需要使用驚人的@NotNull注釋為此工作）。

您在連鎖店中做得更高的事情取決於您：對我而言，將404返回給試圖偽造用戶ID的人聽起來非常接近最佳狀態。