我看到很多资源强烈鼓励程序员不要使用Debug.Trace。由于缺乏引用透明度，来自生产代码。我仍然不完全理解这个问题，并且似乎无法找到根本原因。
我的理解是，跟踪不能改变任何表达式的输出(尽管它在某些情况下会导致表达式以不同的顺序执行，或者导致表达式被评估，否则会被懒惰地跳过)。所以跟踪不会影响纯函数的输出。它不能抛出任何类型的错误。那么，它为什么会受到如此强烈的反对呢？ (如果我上面的任何假设不正确，请指出!)。这只是一场哲学辩论，还是一场表演，或者它实际上会以某种方式引入一个错误？
在使用其他不太严格的语言进行编程时，我经常发现拥有一个感兴趣的生产应用程序日志值来帮助诊断我无法在本地重现的问题很有值(value)。
最佳答案
当然 trace foo bar可以抛出比 bar 更多的错误:它可以(将)抛出任何错误foo扔!
但这并不是避免它的真正原因。真正的原因是您通常希望程序员能够控制输出发生的顺序。您不希望您的调试语句说“Foo 正在发生!”打断自己并说“Foo is hapBar is正在发生!pening!”，例如；并且您不希望潜在的调试语句仅仅因为它包装的值从未被需要而枯萎未打印。控制这个顺序的正确方法是承认你在做IO并将其反射(reflect)在您的类型中。
关于haskell - 为什么 Debug.Trace 是邪恶的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46494499/