編輯：我想我的問題有點漫無目的，可能會減損這一點。因此，儘可能簡潔：我是否應該關注避免因無法使用HTML請求的用戶而導致的異常？正常交互以外的用戶輸入的異常處理
我在HTML中使用了一個由整數值支持的下拉字段。該值在後臺解析。目前，如果整數解析失敗，站點會給出一個通用錯誤（由於頂級異常處理），並將條目放入包含整數解析錯誤的審計線索中。
通常情況下，我不希望不良的用戶輸入引發未處理的異常，但在這種情況下，不好的輸入只能由機器人或聰明的用戶生成。在這兩種情況下，錯誤消息都不會是意外的，並且不應該成爲安全問題。
是否有任何令人信服的理由來處理異常？如果我這樣做，那麼當用戶犯下這個罪行時，我需要正式確定我想要發生的事情。我是否會向機器人和惡意用戶展示他們自己的驗證錯誤？我是否默認他們的值並允許表單提交？
我有答案：這取決於。
例如，如果你正在編寫一個銀行賬戶管理系統，並發現用戶正試圖將他的某個人的「Lorem ipsum」美元轉移到另一個人，那麼這可能是非常糟糕的，你不應該讓這個操作發生。一般錯誤的用戶信息會很好。另一方面，如果你正在寫一個「反向波蘭記號在線計算器」，並遇到「;」字符，您可以向用戶顯示確切的原因。
如果您要驗證用戶的年齡，希望它是0和100之間的整數，但你得到一個2,147,483,647值，那麼它應該是細到只需10
這更像是一個替代它與項目有關的問題而不是技術依賴。
我明白你在說什麼，但我故意不太關心錯誤的嚴重程度，更關心正確的地方處理它的地方（在我的情況下，無論是在頂層異常處理還是在實際網絡方法與默認或驗證。） – Sprague
我認爲答案也涵蓋了，但我錯了。從我的觀點來看，我認爲處理越近的錯誤越容易找到它。但是，如果你**真的**假設這個錯誤不會出現在普通用戶的身上，我會保持高級處理。不知道你正在做什麼樣的項目，很難告訴你一些不那麼普遍的東西。 – Dethariel
我不同意。我認爲異常越接近問題越好。處理的異常永遠不會被開發人員或管理員注意到，除非用戶抱怨應用程序的行爲（可悲的是，他們中很少人甚至做到了這一點！）這是我試圖避免處理不應該出現的異常的一個原因，他們最終會在附近創建普通法特徵。 – Sprague
您是否使用客戶端驗證並希望它不會中斷？ – Dethariel
不，這個項目沒有標準的客戶端驗證。一切都在服務器端進行驗證。 – Sprague