我剛剛遇到了一個捕獲異常（所有異常;我知道這是不好的，但這裏不相關）的屬性setter，並且只有會記錄它們。首先，我認爲它應該再次通過他們;爲什麼要等待崩潰和日誌研究，當你可以馬上知道有什麼事情是錯誤的？我的主要問題是，我是否對無效的日期值進行驗證，向我的文檔上的ValidationRules對象添加一個RuleViolation對象，或拋出一個InvalidDate異常，或者讓CLR爲我拋出異常（無效日期只是無效的日期，沒有檢查範圍等）異常與驗證
只要方法或類成員無法完成設計要完成的任何任務，就應拋出異常。
因此，對於屬性setter，如果setter無法設置屬性，那麼它應該拋出一個異常。
至於你是否應該抓住它並重新拋出它，答案是肯定的，但只有當你需要在設置器中立即處理異常之前，將它傳遞到堆棧之前......但記錄它不是做這件事的理由。一般來說，你應該在更高的層次上執行跨層次的異常日誌記錄，在異常不會被重新拋出的情況下......如果你正在關注堆棧中某些地方的交叉問題， ，絕對不要重新拋出同樣的異常。但是，如果您正在編寫一個工具或框架庫，您希望組件的客戶端擁有一組清晰定義的期望異常，並且您已定義了您的組件將向客戶端代碼拋出的自定義異常，以及哪些客戶端組件期望看到，那麼您可能希望捕獲CLR生成的異常並重新引發您自己的自定義異常。始終在將自定義異常「InnerException」屬性傳遞到堆棧之前包含實際底層異常，所以其中的數據可用於任何最終消耗它的系統。
捕捉和重新拋出是最糟糕的事情。如果你只是想重新推出一下這個觀點，那麼它對TRY來說代價高昂？例如，如果您需要記錄它們，您可以使用catch unhandled exceptions with the global.asax。
在驗證方面，從網絡角度來看，我總是使用正則表達式驗證日期，這些火災的客戶端和服務器端，所以我知道什麼時候
if(Page.IsValid)
塊內部的IM，我txtDate.Text是一個有效的日期，所以我不打擾檢查，因爲它只是浪費。
這取決於具體的任務。如果你正在編寫一個庫類作爲其他程序中的一個組件，並且該類的方法的契約說它只應該接受有效日期，那麼拋出異常就沒有問題。
如果您接受用戶輸入，然後等待異常是一種不好的做法。在這種情況下，你應該自己驗證日期。
例外情況適用於特殊情況，不應該成爲您邏輯的一部分。這通常意味着合同被程序員破壞了。
它真的取決於您的應用程序的邏輯。只有在出現異常的情況下才會拋出異常。對於驗證這樣的事情，取決於對無效數據的容忍度。
當您構建交互式應用程序並且用戶可能輸入任何內容時，文檔進入無效狀態可能是確定的，您應該通過文檔類上的屬性公開驗證信息。
如果您正在處理來自數據庫或日誌文件的預先準備好的文檔，那麼文檔無效並繼續操作可能會破壞系統中的數據可能不正確。當發生這種情況時，你應該拋出
我認爲這取決於日期值的來源。如果它來自用戶輸入或其他可以輸入「無效」日期的其他來源，那麼驗證就是要走的路。另一方面，如果沒有可預見的理由爲什麼數據值可能無效，則拋出異常是適當的。