Go 设计者认为，通过从函数返回错误代码来进行错误处理是惯用的 Go 方式，并且该语言支持多个返回值以使其在语法上变得简单。虽然提供了恐慌/恢复，但区别不在于功能，而在于预期用途。
其他公开异常的语言促进了它们的使用，并且在实践中它们被频繁使用（有时甚至被误用）。
Go 不鼓励使用恐慌/恢复。您可以这样做，但只能在非常有限的情况下这样做。
如果你看看 Go 自己的标准库，大多数 panic 的用途都是用于发出致命错误信号，表明库代码中的内部错误（即 bug）或使用错误的数据调用库（例如，将非 json 数据传递给 json 解码函数）。
但正如您链接到的文章指出的那样：“Go 库中的约定是，即使包在内部使用恐慌，其外部 API 仍然会显示显式的错误返回值。”
这与 C#、Java、Python 或 C++ 等语言不同，在这些语言中，许多标准库代码可以抛出异常来指示错误。这些语言希望您使用异常。 Go 不鼓励使用恐慌/恢复。
总结一下：
惯用的 Go 风格是使用错误代码告诉调用者错误，
仅在极少数情况下使用恐慌/恢复：
当遇到表明代码中存在错误的内部不一致时，使程序“崩溃”。它基本上是一种调试辅助工具。
如果它极大地简化了代码中的错误处理（但如果代码要被其他人使用，则永远不要向调用者暴露此类恐慌）
在实践中，重要的是使用语言的惯用风格。在 Go 中，返回错误代码并避免恐慌/恢复。在 C# 中，这是使用异常来表示某些错误。
panic/recover is moral equivalent of try/catch exceptions. There is superficial difference (syntax) and a subtle, but important, difference of intended use.
The best explanations of problems with exceptions in general is "Cleaner, more elegant, wrong" and that's a good overview of pros/cons of exceptions vs. returning error codes.
Go designers decided that error handling by returning error codes from functions is the idiomatic Go way and the language supports multiple return values to make it syntactically easy. While panic/recover is provided, the difference is not of functionality but intended use.
Other languages exposing exceptions promote their use and in practice they are used frequently (sometimes even misused).
Go discourages the use of panic/recover. You can do it but you're only supposed to do it in very limited scenarios.
If you look at Go's own standard library, most uses of panic are for signaling fatal errors, indicating either an internal error (i.e. bug) in the library code or calling the library with wrong data (e.g. passing non-json data to json decoding functions).
But as the article you linked to points out: "The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values."
This is different from languages like C#, Java, Python or C++, where a lot of standard library code can throw exceptions to signal errors. Those languages want you to use exceptions. Go discourages the use of panic/recover.
To summarize:
idiomatic Go style is to use error codes to tell the caller about errors
use panic/recover only in rare cases:
to "crash" your program when encountering internal inconsistency indicating bugs in your code. It's basically a debugging aid.
if it dramatically simplifies error handling in your code (but if the code is to be used by others, never expose such panics to callers)
In practice the important thing is to use language's idiomatic style. In Go that's returning error codes and avoiding panic/recover. In C# that's using exceptions to signal some of the errors.
发布评论
评论（1）
恐慌/恢复在道德上等同于尝试/捕获异常。存在表面差异（语法）和细微但重要的预期用途差异。
一般来说，对异常问题的最佳解释是 "Cleaner,更优雅，错误” 这是对异常与返回错误代码的优缺点的一个很好的概述。
Go 设计者认为，通过从函数返回错误代码来进行错误处理是惯用的 Go 方式，并且该语言支持多个返回值以使其在语法上变得简单。虽然提供了恐慌/恢复，但区别不在于功能，而在于预期用途。
其他公开异常的语言促进了它们的使用，并且在实践中它们被频繁使用（有时甚至被误用）。
Go 不鼓励使用恐慌/恢复。您可以这样做，但只能在非常有限的情况下这样做。
如果你看看 Go 自己的标准库，大多数 panic 的用途都是用于发出致命错误信号，表明库代码中的内部错误（即 bug）或使用错误的数据调用库（例如，将非 json 数据传递给 json 解码函数）。
但正如您链接到的文章指出的那样：“Go 库中的约定是，即使包在内部使用恐慌，其外部 API 仍然会显示显式的错误返回值。”
这与 C#、Java、Python 或 C++ 等语言不同，在这些语言中，许多标准库代码可以抛出异常来指示错误。这些语言希望您使用异常。 Go 不鼓励使用恐慌/恢复。
总结一下：
在实践中，重要的是使用语言的惯用风格。在 Go 中，返回错误代码并避免恐慌/恢复。在 C# 中，这是使用异常来表示某些错误。
panic/recover is moral equivalent of try/catch exceptions. There is superficial difference (syntax) and a subtle, but important, difference of intended use.
The best explanations of problems with exceptions in general is "Cleaner, more elegant, wrong" and that's a good overview of pros/cons of exceptions vs. returning error codes.
Go designers decided that error handling by returning error codes from functions is the idiomatic Go way and the language supports multiple return values to make it syntactically easy. While panic/recover is provided, the difference is not of functionality but intended use.
Other languages exposing exceptions promote their use and in practice they are used frequently (sometimes even misused).
Go discourages the use of panic/recover. You can do it but you're only supposed to do it in very limited scenarios.
If you look at Go's own standard library, most uses of panic are for signaling fatal errors, indicating either an internal error (i.e. bug) in the library code or calling the library with wrong data (e.g. passing non-json data to json decoding functions).
But as the article you linked to points out: "The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values."
This is different from languages like C#, Java, Python or C++, where a lot of standard library code can throw exceptions to signal errors. Those languages want you to use exceptions. Go discourages the use of panic/recover.
To summarize:
In practice the important thing is to use language's idiomatic style. In Go that's returning error codes and avoiding panic/recover. In C# that's using exceptions to signal some of the errors.