Go的函数参数验证使用错误是一个好的模式吗？ [英] Is function parameter validation using errors a good pattern in Go?
问题描述
使用错误返回码进行参数验证被认为是良好实践吗？我的意思是在哪里应该有人使用错误与恐慌（是否有任何指引？）。
例如：
- 检查non-nil +是否返回一个错误，如果它不是一个好的
练习？ - 或者检查正确的整数范围等。 li>
我想象一下，使用经常会让Go感觉非常糟糕的错误并且看起来很糟糕。恐慌在这些情况下是一种很好的选择吗？
或者Gopher应该使用Python / Ruby / JS方法让它失败？
我有点困惑，因为在我的理解中，恐慌是真正的错误。但是，一直使用错误只是不好。
即使我会返回错误代码：如果有人将错误的参数传递给我的函数但忽略错误代码，我该怎么办？ - >没什么！所以老实说，我会说恐慌对于那些情况来说很好，但是在错误代码被用于恐慌情况下的语言中，这并不是非常清楚。
另一方面，诸如未能打开文件或其他操作的问题你的函数应该在调用正确的时候执行而不是导致 请注意，在.NET和Java的公共API函数中显式检查 TL; DR 关于处理运行时问题， 1 Is parameter validation using error return codes considered good practice ? I mean where should somebody use errors vs panics (are there any guidelines?). For instance: I imagine that using errors that often would make Go feel very C-ish and would look pretty bad. Are panics a good alternative in those situations ? Or should a Gopher use the Python/Ruby/JS-approach "just let it fail" ? I'm a bit confused because panics are for real "errors" in my understanding. But using errors all the time is just bad. And even if I would return error code: What could I do if somebody passes wrong parameter to my function but ignores the errors codes ? -> Nothing! So honestly I would say panics are nice for those situations but in a language where error codes are used over panics this is not very clear. "Escaping" On the other hand, problems like failure to open a file or pefrorm some other action your function is supposed to perform when called correctly should not cause Note that the recommendation for explicit checking for TL;DR With regard to processing of run-time problems, 1 Another legitimate use for 这篇关于Go的函数参数验证使用错误是一个好的模式吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！ panic s 1 （我的意思是，那些可能由包中的公共API ）是为了处理错误程序员所做的。所以，如果你的函数得到一个指向一个对象的指针，并且不能是 nil （比如说，为了表明这个值已经丢失），那么继续进行并取消引用指针如果它碰巧是 nil ，则使运行时 panic 本身。如果一个函数需要一个必须在一定范围内的整数， panic 如果它不在该范围内 - mdash;因为在正确程序中，可能传递给你的函数的所有值都在范围内，如果它们不是，则程序员不遵守API或他们没有净化从外部获得的价值，这也不是你的错。
panic s并且函数应该返回一个恰当的错误。
null 参数的建议代码具有不同的目标，使得这种类型的错误更具可读性。但是，因为99％的.NET和Java代码只是让所有异常传播到顶层（然后被显示或可能被记录），它只是用另一个替代（由运行时生成的）异常。这可能会使错误更加明显 - API函数中的执行失败，而不是深入调用堆栈的某个位置 - 但会为这些API函数添加不必要的错误。所以，是的，这是自以为是的，但我的主观意见是：让它只是崩溃在Go中可以 - 你会得到一个描述性的堆栈跟踪。
panic s用于编程错误;
panic s是从深度递归处理/计算返回的快速冷路径;在这种情况下，应该由你的包捕获和处理 panic ，并且相应的公共API函数应该返回错误。请参阅此和这个获取更多信息。
panics1 in Go (I mean, those which might be produced by the functions comprising the public API of your package) are to deal with errors programmers do. So, if your function gets a pointer to an object, and that can't be nil (say, to indicate that the value is missing) just go on and dereference the pointer to make the runtime panic itself if it happens to be nil. If a function expects an integer that must be in a certain range, panic if it's not in that range — because in a correct program all values which might be passed to your function are in that range, and if they don't then either the programmer failed to obey the API or they did not sanitize the value acquired from the outside which, again, is not your fault.panics and the function should return an appropriate error instead.null parameters in the functions of public APIs in .NET and Java code has different goal of making such kinds of errors sort-of more readable. But since 99% of .NET and Java code just lets all the exceptions propagate to the top level (and then be displayed or may be logged) it's just replacing one (generated by runtime) exception with another. It might make errors more obvious—the execution fails in the API function, not somewhere deeper down the call stack—but adds unnecessary cruft to these API functions. So yes, this is opinionated but my subjective opinion is: to let it just crash is OK in Go—you'll get a descriptive stack trace.
panics are for programming errors;
panics is quick "cold-path" returning from deep recursive processing/computation; in this case panic should be caught and processed by your package, and the corresponding public API functions should return errors. See this and this for more info.
