此Console.WriteLine语句中的错误在哪里？

Question

如果您运行以下代码,您将获得输出:

答案是:<br>
<br>

class Program
{
    static void Main(string[] args)
    {
        HtmlElement element = new HtmlElement();
        element.InnerHtml = "<br>";

        string val = element.InnerHtml != null ? element.InnerHtml : element.InnerText != null ? element.InnerText : element.TagName;
        Console.WriteLine("The answer is: "+val); // correct
        Console.WriteLine("The answer is: " +element.InnerHtml !=null ? element.InnerHtml : element.InnerText != null ? element.InnerText : element.TagName); // bug?
        Console.ReadLine();

    }
}
public class HtmlElement
{
    public string InnerHtml { get; set; }
    public string InnerText { get; set; }
    public string TagName { get; set; }
}

第二行发生了什么,预计将是:

答案是:<br>

只是为了澄清任何想知道的冲浪者的答案:

Console.WriteLine("The answer is: " +element.InnerHtml !=null ? element.InnerHtml : element.InnerText != null ? element.InnerText : element.TagName); // bug?

被评估为

Console.WriteLine(("The answer is : " + element.InnerHtml != null) ? element.InnerHtml : element.InnerText != null ? element.InnerText : element.TagName); // bug?

Answer 1

你The answer is: " +element.InnerHtml优先于!= null.

重写为:

Console.WriteLine("The answer is: " + (element.InnerHtml !=null ? element.InnerHtml : element.InnerText != null ? element.InnerText : element.TagName)); // bug?

(添加括号)

Answer 2

这是一个优先问题.你的陈述:

"The answer is: " + element.InnerHtml !=null ? element.InnerHtml : ...

应评估为:

"The answer is: " + (element.InnerHtml !=null ? element.InnerHtml : ...)
                    <------------------- this first ------------------->

但实际上评估为:

("The answer is: " + element.InnerHtml) !=null ? element.InnerHtml : ...
<------------- this first ------------>

最后一个表达将永远是真的,因为"string" + anything != null,所以你总是会得到element.InnerHtml (<br>).

您在第一次测试中没有问题的原因是因为您正在val单独评估,因此手动控制优先级.

顺便说一句,我喜欢人们似乎认为他们在数百万其他人使用的软件中发现了一个错误的方式,而不是考虑他们可能做错了什么的最轻微的可能性:-)

虽然说实话,我发现许多人使用的一个产品中存在漏洞(如果我没记错的话,是Microsoft COBOL编译器),但这是由于签名/未签名问题,我有一台最早的内存超过512K的机器(检查启动代码以确保您有足够的内存,并将640K视为负数量.

尽管如此,在四分之一世纪中发现的一个错误相当低,所以不应该假设软件立即出现故障.我的第一个想法总是我以某种方式填满了(而且我通常是对的,这让我很懊恼).