返回null或拋出異常一次

Question

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

1. 如果你總是希望找到一個值，則拋出如果缺失則爲異常。這個例外意味着有問題。如果該值可能丟失或存在，並且兩者都對應用程序邏輯有效，則返回null。
2. 只有在發生異常時纔會拋出異常。如果預期該對象的行爲不存在，則返回null。

但是我應該如何解釋他們在我的（這麼隨便）情況： 我的web應用程序控制器接收請求顯示詳細信息具有一定的ID的用戶。控制器要求服務層獲取用戶，然後服務返回該對象（如果找到）。如果不是，則發送到「默認」位置的重定向。

如果有人在請求URL中傳遞了無效的用戶標識，該怎麼辦？我是否應該將其視爲「預期的行爲」並將null返回給控制器，或者我應該將其稱爲「問題或意外行爲」，從而在服務方法內引發異常並捕獲到控制器中？

從技術上來說，畢竟這並不是什麼大的差別，但我想按照標準召集的方式來做正確的做法。在此先感謝您的任何建議。

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

Answer 1

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

要點是，無論您是拋出異常還是返回null，只要確保最外層過濾器或處理程序在響應之前「記錄」了詳細信息返回給用戶。

Answer 2

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

（OTOH如果在請求中的用戶ID被自動由另一個應用程序所產生/從DB等，未來的用戶ID無效。將意外，從而異常將是適當的。）

Answer 3

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

你必須兩種選擇：顯示您提到的「默認」頁面或返回「未找到」/ 404。

關於null，這取決於。如果考慮空不可接受的參考，然後用@NotNull和註釋註釋應需要時得到一個空參考做正確的事情吧：那是，拋出（未經檢查的）異常（當然你需要使用令人驚歎的@NotNull註釋才能工作）。

你在鏈條上的做法取決於你：對於我試圖僞造用戶ID的人返回404聽起來非常接近最佳。