问题标签 [fail-fast-fail-early]

关于数据验证，我听说选项是“快速失败，早期失败”或“完全验证”。第一种方法在第一个验证错误上失败，而第二种方法建立一个失败列表并显示它。

我想知道在服务器端和客户端数据验证的上下文中。哪种方法适合什么情况，为什么？

我个人对客户端数据验证的偏好是第二种方法，它通知用户所有失败的约束。尽管我认为这取决于所涉及的业务逻辑，但我没有足够的信息对服务器端发表意见。

“尽早失败”是什么意思，在什么情况下这种方法最有用，你什么时候避免这种方法？

我一直（多年来）想知道实现以下最有意义的方式（这对我来说有点自相矛盾）：

想象一个函数：

它被称为：

但是，要捕获 ArgumentNullException，我应该这样做：

要不就：

?

如果满足某些条件，我有一个返回字符串数组的函数。但我想在我的函数中有提前返回功能。像这样的东西：

但我面临以下问题：

Nil 与返回类型“[String]”不兼容

我试着只写return声明。但它也失败了。该怎么办？

编辑：1

如果我只想从此函数返回而没有任何价值怎么办。回到调用这个函数的那一行。就像是：

我知道脚本中有几个关于exitvs.return的问题（例如这里）。bash

关于这个话题，但与现有问题不同，我相信，我想知道是否有“最佳实践”来安全地从bash脚本中实现“提前返回”，这样如果他们不退出用户当前的 shell源脚本。

诸如此类的答案似乎基于“ exit”，但如果脚本是来源的，即使用“ .”（点空间）前缀运行，则脚本在当前 shell的上下文中运行，在这种情况下，exit语句具有退出的效果当前外壳。我认为这是一个不受欢迎的结果，因为脚本不知道它是被获取还是在子 shell 中运行 - 如果是前者，用户可能会意外地让他的 shell 消失。如果调用者来源它，是否有提前返回不退出当前 shell 的方法/最佳实践？

例如这个脚本...

...如果它是从子外壳运行的，则运行时不会杀死我当前的外壳...

...但是如果它是有源的，它会杀死我当前的外壳：

想到的一个想法是将代码嵌套在代码中，这样就没有明确的exit声明，但是我的C/C++偏见使认为提前返回在美学上比嵌套代码更可取。还有其他真正“早退”的解决方案吗？

如果我希望switch(an_enum)在错过枚举案例时报告我的语句，我可以打开-Wswitch编译器标志（在 gcc 上）。

它工作得很好：“错误：枚举值'e3'未在开关[-Werror = switch]中处理”

但是现在我的代码的正确性取决于使用的编译器标志，这有点脆弱。

像这样的东西：

-Wswitch如果标志关闭，有没有办法让那段代码失败？还是在代码中临时打开它？

我想知道除了 common 之外是否还有一种方法可以检查指针的有效性assert(NULL != ptr)。我尝试了以下故意引发“访问错误”，因此我会及早收到警报，而不是最近在某些嵌套代码中访问指针时：

关于这个话题有什么建议吗？

所需用例：

作为先决条件，完全可以接受 IDE 在访问错误时将我扔到调试器中。在我的情况下，我不会从命令行或 IDE 之外的某个地方运行调试构建。

我对其他编程语言的期望是(1:4)[3:5]并且list(asdf = 4, qwerty = 5)$asdg都应该引发异常。相反，第一个静默返回c(3, 4, NA)，第二个静默返回NULL（如 or 一样list(asdf = 4, qwerty = 5)[[asdg]]）。

虽然这种行为有时会很有用，但更常见的是（根据我的经验），它会变成一个小错字、一个错误，或者无法在任何地方重命名变量，因为它从触发器中使用，以便立即轻松地使用-to-debug 错误，当静默传播NULL的 s 或NAs 最终被输入到一个对它们来说很响亮的函数或操作时，触发一个真正令人费解的错误，大约 20（或 200）步。（当然，这仍然比它根本不产生错误，只是垃圾结果的时候要好。）

data.frame()[,'wrong']给出一个错误，但data.frame()['wrong',]只返回NA.

我正在寻找的是一种方法来做向量/数组/列表/data.frame/等。如果我使用无效的索引，下标/成员访问将立即可靠地导致错误。对于列表，get('wrong', list())我正在寻找什么，但这有时会非常难看（特别是如果使用结果作为下标其他内容）。它是可用的，但更好的东西会很好。对于向量（和 data.frame rows），即使这样也行不通。

有没有好的方法来做到这一点？