-
Notifications
You must be signed in to change notification settings - Fork 698
Raising custom error types/ const errors #160
Comments
you can always wrap it again |
https://dave.cheney.net/2016/04/07/constant-errors Which contains, "Although, you really shouldn’t be using sentinel errors anyway." |
The errors package explicitly makes it hard to use for Singleton errors.
I suggest using the stdlib errors.new and wrapping when needed.
… On 19 Jun 2018, at 03:50, 哲の王 ***@***.***> wrote:
you can always wrap it again
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Understood and thank you for your blog posts.
That works but still doesn't deliver and entirely "clean" stack trace as I'd desire. Bottom line- with my limited go experience- seems to be that you cannot test wrapped (top-level) errors for behaviour (need to use causer instead) and stack traces will contain both inner error creation plus wrapping when "throwing" for that reason. |
I recommend using pkg/errors.New at the point you need to return an error.
You won’t be able to compare that error value to another other than nil, but that’s the point.
If you do need to use a sentinel error value, then pkg/errors is not the tool for you. It’s deliberately design so that it’s errors are not comparable for reasons that I outlined in my blog post.
… On 19 Jun 2018, at 16:13, andig ***@***.***> wrote:
The errors package explicitly makes it hard to use for Singleton errors.
Understood and thank you for your blog posts.
I suggest using the stdlib errors.new and wrapping when needed.
That works but still doesn't deliver and entirely "clean" stack trace as I'd desire. But it seems to be as good as it will get.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Indeed, I recall in a previous bug/feature discussion, I suggested making a nicer Sentinel const-compatible type, and the recommendation was, “if we make it easier, people will use it, and we would like to actually discourage it.“ But regardless, a “good sentinel” value can be had with just a few lines of code. Sure the type ends up being unique to your package, (and hopefully actually unexported) but these are parts of what should hopefully make sentinel errors better than As a note, the stdlib errors is not const-compatible, so. 😐 |
I'm sorry I haven't replied before now. |
Fixes #160 Fixes #107 Signed-off-by: Dave Cheney <[email protected]>
Fixes #160 Fixes #107 Signed-off-by: Dave Cheney <[email protected]>
The io package declares an EOF error like this:
using this pattern to raise custom errors leads to ugly stack traces since the errors are generated during intialization, not when they happen:
in fact, the entire call stack of where is error happens is lost which means using the error type is impossible.
How could one implement custom error types or errors the can be behaviour-checked according to your blog article?
The text was updated successfully, but these errors were encountered: