《领域特定语言》一3.7 错误处理

3.7 错误处理

每次写作一本书，我都会到达一个时刻，我意识到，如同做软件一样，只有削减范围，书才能出版。然而，这就意味某些重要的主题无法妥善涵盖。但是，一本有用却不完整的书总好过一本完整却永远也不能完成的书。本书有很多主题，我想进一步探索，排在第一位的就是错误处理。
在大学的编译课上，我记得老师说过：解析和生成输出是编写编译器中容易的部分─真正的难点在于，给出更好的错误消息。相应地，错误诊断就超出了那堂课的范围，对于本书也一样。
体面的错误消息“超出范围”在现实中会更进一步。即便是一些成功的DSL，良好的诊断信息也极其罕见。许多广泛使用的DSL包在提供有用信息方面所做有限。Graphviz是我最喜欢的DSL工具之一，当错误发生时，它只会简单地告诉我syntax error near line 4，我还感到几分幸运，因为它竟然还能给出行号。我确实遇到了很多工具，只是直接失败，我只能通过注释代码，以二分查找的方式定位问题。
我们可以批评一个系统没有提供良好的错误诊断，但是错误诊断也是一件需要折衷的事情。多花一分时间在错误处理上，就意味要少花一分时间在功能添加上。许多来自现实世界DSL的证据都表明，人们的确可以忍受表现不佳的错误诊断。毕竟，DSL脚本很小，相比于通用语言，粗糙的错误处理也是可以接受的。
这么说并不是劝你不要在错误诊断上花时间。对一个使用频率很高的程序库而言，良好的错误诊断可以帮助我们节省很多时间。每次折衷都有所不同，需要根据自己的环境决定。确实，这种说法会让我不再为“没有在本书为这个主题开辟一节”感到太多内疚。
虽然不能如我所愿般对这个话题做深入探讨，但如果你决定提供更好的错误诊断支持，我希望我所说的这些可以让你开始对其有更多的思考。
（我应该谈一下最暴力的一种错误查找技术：注释。如果要用外部DSL，请确保它可以支持注释。并不只是为了那个显而易见的原因，它还可以帮助人们找到问题。以换行符结束的注释是最方便的。针对不同的受众，我会使用“#”（脚本风格）或者“//”（C风格），这些都可以通过一条简单的词法分析规则实现。）
如果你遵循我的一般建议，采用“语义模型”（第11章），那么有两个地方可以放置错误处理：模型或者解析器。对于语法错误，处理它最明显的地方就是解析器。有些语法错误有人会替我们处理，比如内部DSL中宿主语言的语法错误，或是使用“解析器生成器”（第23章）时外部DSL中的文法错误。
在处理语义错误时，要从解析器和模型中进行选择，二者各有其优。如果要检查语义规则是否结构良好，模型是一个正确的地方。我们拥有所有的信息，这些信息以思考所需的方式组织，所以，在这里可以写出最清晰的错误检查代码。此外，如果要在多个地方组装模型，比如，有多个DSL或者用到命令–查询接口，模型也是最合适进行检查的地方。
纯粹把错误处理放在语义模型中，确实有个严重的问题：无法链接回DSL脚本中出问题的源码，甚至无法得到一个大概的行号。这会使定位错误越发困难，但这也可能不是一个棘手的问题。一些经验表明，在多数情况下，纯粹基于模型的错误消息已足以帮我们找到问题。
如果确实需要，我们还是有办法拿到DSL脚本的上下文。最显而易见的一种做法就是把错误检测规则放在解析器中。不过，这种做法的问题在于，它会让编写规则变得更加困难，因为在这种情况下，我们是在语法树的层次上进行工作，而不是在语义模型的层次上。另外，我们还要承担规则重复带来的极大风险，正如代码重复所带来的问题一样。
另一种可选方案是，把语法信息放入语义模型。比如，在语义转换对象中添加一个记录行号的字段，这样，如果语义模型在转换中检测到错误，就可以输出脚本中的行号。问题是，由于要跟踪信息，这种做法会让语义模型变得更加复杂。此外，脚本与模型之间的映射可能并不那么清晰，所以，错误消息非但无益，反而会让人困惑。
第三种，也是我认为最好的一种方案是：使用语义模型检测错误，但是，错误检测的触发是在解析器中。具体来说，就是解析器解析一大块DSL脚本，组装出语义模型，然后让模型去找错误（如果组装模型时并不直接这么做的话）。如果模型发现任何错误，解析器都可以拿到这些错误，提供其所知的上下文。这样，就分离了对语法知识（在解析器中）和语义知识（在模型中）的关注。
还有一种有用的方法是，把错误处理分为初始、检测和报告三个阶段。最后一种方案是，把初始化放在解析器中，把检测放在模型中，报告则二者皆有，模型负责提供错误的语义，解析器负责添加语法上下文。