為什么條件方法的返回類型必須為void？

Question

我們正在為我們的API編寫一些全局異常處理程序，我們只需要在Debug配置中執行某些方法，顯然條件方法是可能的解決方案。

然而，我看到[Conditional("DEBUG")]只能用於返回類型為void的方法，如MSDN所說：

條件方法受以下限制：

• 條件方法必須是類或結構聲明中的方法。 如果在接口聲明中的方法上指定了Conditional屬性，則會發生編譯時錯誤。
• 條件方法必須具有返回類型void 。
• 不能使用override修飾符標記條件方法。 但是，條件方法可以用虛擬修飾符標記。 這種方法的覆蓋是隱式條件的，不能用條件屬性明確標記。
• 條件方法不能是接口方法的實現。 否則，發生編譯時錯誤。

資料來源： https ： //msdn.microsoft.com/en-us/library/aa664622（v = vs.71）.aspx

我們知道用ConditionalAttribute標記的方法到達了IL，那么為什么CLR只是簡單地攔截返回default(T)方法調用，因此允許任何類型的返回類型的方法都是有條件的？ 或者我錯過了什么？

Answer 1

為什么不CLR只是攔截方法調用返回default(T)

更重要的是...... 為什么會這樣？ 如果沒有令人信服的理由這樣做，那么沒有令人信服的理由投入大量精力，工時，成本等來進行辯論，設計，考慮所有可能的情景，開發，測試和繼續在所有未來版本的語言中支持它。 這對於首先不需要的功能來說是非常顯着的節省。

void方法保證沒有結果。 因此，已經存在一個邏輯保證，即沒有任何東西依賴於它的結果。 返回值的方法不能提供這樣的保證。

由於沒有任何依賴於其結果，省略它不會改變代碼/邏輯的直接本地行為。 如果某些事情確實依賴於其結果（或者至少可能依賴於其結果），那么本地行為可能會改變，這是不可取的。 這種情況可能會帶來許多意想不到的變化。 即使是在代碼不期望null返回null也很簡單。

人們可以親自堅持認為，可以考慮自己的邏輯，並在編譯器可以保證的范圍之外做出自己的保證。 （類型轉換和反射之類的東西對於開發人員來說可能是有用的工具，前提是他們可以保持他們認為可以的穩定性。）但在這種特殊情況下， 很快就會成為開發代碼和生產代碼不再需要的問題。一樣。 他們可能會做非常類似的事情，但不再是同樣的事情。 這是一個重大問題，語言試圖避免這種情況。

這不是什么可以制做。 我確信，鑒於當時存在的信息，任何給定語言的任何給定版本都可以支持各種各樣的事物。 但是應該嗎？ 這完全是另一個問題。 在這種情況下，似乎支持這一點的成本將大大超過人們可能從中獲得的成本。