我想用实验性编程语言实现的主要内容之一是：当出现错误（语法，名称，类型等）时，无论程序有多严重或多么严重，都要保持程序正常运行。 我知道这可能非常糟糕，但我只想要一些不会在每次错误中自行解决的问题 - 我发现当发生严重错误但程序仍在继续时会发生什么。
答案 0 :(得分：4)
在命名上，你可以说语言表现出“猪头”。
通常首选崩溃，因为程序不应返回不可预测且不可重复的结果。没有结果通常比不可靠的结果更好，特别是如果你做一些关键业务。例如，最好不要处理客户在亚马逊上的订单（他们总是可以重新提交），而不是为客户提供随机产品。某些错误确实无法恢复，例如，如果指令指针已损坏。
您可以在大多数现代语言中实现类似的bahaviour，并捕获所有异常处理程序。
答案 1 :(得分：2)
为了让你的程序继续进行，你必须拥有一个你知道是好的基本状态，然后每个请求都是独立处理的。例如：
如果您这样做，最值得注意的是您的应用程序必须具有一些无错误的核心，并且将处理任何计划外异常（不是一项简单的任务） 。更不用说吞下意外的异常会使故障排除/调试变得悲惨，不可减少的核心不会失败，否则整个应用程序都会失败。
答案 2 :(得分：1)
我选择了处理错误的“军事拓扑”方法。
错误应按严重程度进行分类，然后处理或传递给上级解决。
私人被命令用牙刷清洁游行场地。他用完了肥皂。这是一个他应该弄清楚自己而不是打扰他的上司的问题。
如果阅兵场上有一排敌人的士兵，那么他应该告诉他的上司。
当你有钱有名时，请相信你书中的'snark'部分。
答案 3 :(得分：0)
我不知道名字。
有多糟糕？我不知道;你用它做什么用的？通常，崩溃比静默错误更好。崩溃是显而易见的，通常可以纠正，但是沉默的错误可能会被忽视，因此纠正它们并不容易。
在某些情况下，这可能是正确的做法。我读过海军消防控制计算机带有“战斗条”，禁用了异常设施，理由是只要它运行它可能会提供良好的信息，而如果它没有运行你就会非常清楚事实并非如此。在战斗中，即使你不能做一些特别有用的事情，也常常无所事事。
答案 4 :(得分：0)
您假设可以确定X类型的所有错误都是show-stoppers，而Y类型的所有错误都不是。我认为这表面看起来不错，但魔鬼在细节中。在实践中，我认为你不会想到一个总是良性的错误。
你提到“语法，名称，类型”。如果您知道常见的语法错误可以客观地修复而不会导致问题，请将它们构建到规范中并让编译器处理它们（此时它们将不再是语法错误）。我不知道“名字”指的是什么样的琐碎错误。避免类型错误是一个动态类型系统的问题。同样，这是规范的一部分，而不是错误处理。
我正在阅读的是你想要一个特定的规范，一个多功能的编译器，允许以各种方式编写语法，以及动态类型系统。这太棒了，祝你好运。但是，不要将此与解释编码人的意向性混淆，并认为你可以从一个有害的错误中判断出错误。
答案 5 :(得分：0)
在我看来，你在谈论正确性和健壮性之间的区别。无论如何，一个非常强大的程序可以继续运行高度正确的程序只能提供正确的输出。这两种品质往往是截然相反的，必须相互平衡。没有一般方法可以决定两者之间的平衡。这取决于该计划的目的。因此，编译器无法智能地决定它应该支持哪种方式。
稳健性编程不一定是坏事。例如，设备驱动程序往往非常强大（至少是好的驱动程序）。一般来说，面对意外错误，设备驱动程序爆炸是不可能的，因为这可能会导致整个系统崩溃。设备驱动程序通常会以您描述的“我不关心”的方式解释“致命”错误。例如，如果硬件发送损坏的数据，通常只需丢弃它并等待新的样本即可。