英文:
How to check function parameters in Go
问题
Guava Preconditions允许在Java中轻松检查方法参数。
public void doUsefulThings(Something s, int x, int position) {
checkNotNull(s);
checkArgument(x >= 0, "Argument was %s but expected nonnegative", x);
checkElementIndex(position, someList.size());
// ...
}
如果条件不满足，这些检查方法会引发异常。
Go语言没有异常，但通过返回值指示错误。因此，我想知道上述代码的Go语言版本会是什么样子。
英文:
Guava Preconditions allow to check method parameters in Java easily.
public void doUsefulThings(Something s, int x, int position) {
checkNotNull(s);
checkArgument(x >= 0, "Argument was %s but expected nonnegative", x);
checkElementIndex(position, someList.size());
// ...
}
These check methods raise exceptions if the conditions are not met.
Go has no exceptions but indicates errors with return values. So I wonder how an idiomatic Go version of the above code would look like.
答案1
得分: 2
这取决于上下文。
如果doUsefulThings是从一个包中导出的公共函数，返回一个error。你可以有导出的包级别的error变量，你可以返回它，调用者可以检查返回的error是否等于文档化的错误方式之一。
如果它没有被导出，并且以错误的方式调用它是程序员的错误，我认为panic(errors.New("bla bla bla"))是合理的。尽管一旦你解引用了那个指针，函数会发生panic。
对于这个：checkArgument(x >= 0, "Argument was %s but expected nonnegative", x)，你可以传入uint。
英文:
It depends on context.
If doUsefulThings is a public function exported from a package, return an error. You can have exported package level error variables that you can return, and the caller can check if the returned error is equal to one of the documented ways to screw up.
If it's not exported, and it would be a programmer error to call it incorrectly, I think it's reasonable to panic(errors.New("bla bla bla")). Although the function would panic once you dereferenced that pointer, anyway.
For this: checkArgument(x >= 0, "Argument was %s but expected nonnegative", x) you can pass in uint.
答案2
得分: -1
我不确定使用断言来检查参数的基本属性是否符合语言的哲学。
对于可能具有无效值的参数（例如在数据库中找不到），您将返回错误：
func doUsefulThings(s *Something) error {
// 如果您的算法检测到无效值，则返回错误
断言s不是nil只会增加冗余。验证您没有提供nil是没有意义的。
添加返回参数，特别是error，强制所有用户检查此错误。不要在函数中编写代码来防御调用者代码中的微不足道的错误。在调用您的函数之前，调用者应该简单地测试它不是nil，如果根据代码的其余部分可能的话。
英文:
I'm not sure using assertions to check basic properties of the parameters is in the philosophy of the language.
In case of a parameter which really could have an invalid value without bug (for example you don't find it in database), you would return an error :
func doUsefulThings(s *Something) error {
// return an error if your algorithm detect an invalid value
Asserting that s isn't nil would only add verbosity. There is no point in verifying you weren't provided nil.
Adding a return parameter, especially error forces all users to check this error. Don't write code in your function to defend against trivial bugs in the caller code. The caller should simply test it's not nil, if that's possible depending of the rest of the code, before calling your function.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论