C# 正在检查OpenFileDialog的可空结果

我在WPF应用程序中编写了一些代码，如下所示：

var dialog = new OpenFileDialog { Filter = this.FileExtensionFilter };
var dialogResult = dialog.ShowDialog();
if (dialogResult.HasValue && dialogResult.Value)
{
    ... Process result of dialog ...
}

我想，一切都很好，但ReSharper在检查dialogResult.HasValue时提出了一个警告，“表达式始终为真”

第一个问题是ReSharper如何知道dialogResult总是有一个结果-它一定是直接跳入Microsoft.Win32.OpenFileDialog类的反编译代码，并观察到它从不返回null。要么就是这样，要么就是专门针对此类的硬编码警告

其次，仅仅假设结果永远不会为空似乎不是好的做法。如果Microsoft发布了该库的未来版本，其中的空值变为可用，该怎么办？关于此事的文件说：这确实意味着这不是一个我们可以永远依赖的永久性安排

---

有没有想过我是否过于谨慎，是否应该按照ReSharper的建议删除这条线？

这确实有些奇怪。MSDN规范声明它将返回true或false，但仍然必须有可为空的原因

我完全同意你的观点，假设下面有一个实现是不好的做法。我会按照接口编码，所以在这种情况下，我认为检查HasValue是正确的方法

Re sharper怎么知道的？恐怕我不能回答这个问题。这不是我用的东西，他们可能已经硬编码了

您可能对此感兴趣：

可能出现null的原因似乎是因为这是用户关闭对话框之前的结果。

它是硬编码的

如果您查看程序文件中的ReSharper目录，您将看到许多名称中带有null.Gen的XML文件，这些文件包含关于特定元素是否为null的规则，这些规则用于显示警告，例如您看到的警告，这些警告通常不会显示

如果在Bin\ExternalAnnotations.NETFramework\System.Windows中找到2.0.5.0.Nullness.Gen.xml文件，您将在大约一半的地方找到以下条目：

<member name="M:System.Windows.Controls.OpenFileDialog.ShowDialog">
    <attribute ctor="M:JetBrains.Annotations.NotNullAttribute.#ctor" />
</member>

---

回答问题的另一半做得很好-我相信这是JetBrains的一个错误，而且API不会返回null的假设非常糟糕，这只是一个实现细节。感谢您澄清这个JMK。我同意@Ian的观点，做这样的硬编码假设似乎是一种糟糕的编程实践。公共接口通常应该被视为黑匣子，如果它有一个可为空的返回类型，你应该满足它。很遗憾，我不能将两个答案都标记为可接受，因为它们都回答了多个问题的不同部分！不管怎样，这两个选项都要向上投票。@Ian的答案更有用，所以我没有抱怨：）

 <member name="T:JetBrains.Annotations.NotNullAttribute">
     <summary>
     Indicates that the value of the marked element could never be <c>null</c>
     </summary>
     <example><code>
     [NotNull] public object Foo() {
       return null; // Warning: Possible 'null' assignment
     }
     </code></example>
 </member>