In every documentation, I read something like that for sentinel errors:

Sentinel errors are usually used to indicate that you cannot start or proceed.

That could also be the case for any possible error, isn't it? Because anything unexpected can happen in Runtime. Does it mean errors that I expect in Runtime but can or should handle better, do I call sentinel errors?

Then I read how they should be used:

Sentinel errors are among the few variables declared at the package level. Their names start with Err (Exception io.EOF). They should be threatened as read-only. (Go compiler cannot enforce this).

Before you define a sentinel error, make sure you need one. Once defined, it becomes part of your public API, and you have committed to making it available in all future backwards-compatible releases.

Or does the way I handle them make them sentinel errors? Could you give me an example to understand clearly, what the difference is?

Would it be wrong to say: Errors, I want to stand sentinel over in Runtime, and I explicitly define in my package root as variables (or constants) are sentinel errors?

I've prepared an example; maybe we can use it as a basis: https://go.dev/play/p/qwi4ligYZYh

CodePudding user response：

Ben, yes, as soon as you have defined in your package root possible expected runtime errors that you want to handle, they are sentinel errors.

Its name giver is Dave, here more about him and his explanation: Don’t just check errors, handle them gracefully. Maybe he can tell you more.

As far as unterstood, they want to make you aware that it will become part of your public API and you will have to maintain it in later versions of your package as well, as you already wrote.

I think the name "sentinel" is quite appropriate, in German "Wachposten".