Skip to content
This repository has been archived by the owner on Dec 1, 2021. It is now read-only.

Raising custom error types/ const errors #160

Open
andig opened this issue Jun 18, 2018 · 7 comments
Open

Raising custom error types/ const errors #160

andig opened this issue Jun 18, 2018 · 7 comments

Comments

@andig
Copy link

andig commented Jun 18, 2018

The io package declares an EOF error like this:

var EOF = errors.New("EOF")

using this pattern to raise custom errors leads to ugly stack traces since the errors are generated during intialization, not when they happen:

github.com/andig/gosml.init
        /Users/andig/Documents/htdocs/go/src/github.com/andig/gosml/crc16.go:32
main.init
        <autogenerated>:1
runtime.main
        /usr/local/opt/go/libexec/src/runtime/proc.go:186
runtime.goexit
        /usr/local/opt/go/libexec/src/runtime/asm_amd64.s:2361

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?

@CreatCodeBuild
Copy link

you can always wrap it again

@puellanivis
Copy link

puellanivis commented Jun 18, 2018

@davecheney
Copy link
Member

davecheney commented Jun 18, 2018 via email

@andig
Copy link
Author

andig commented Jun 19, 2018

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.

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.

@davecheney
Copy link
Member

davecheney commented Jun 19, 2018 via email

@puellanivis
Copy link

puellanivis commented Jun 19, 2018

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 var EOF = errors.New("EOF") with all the pitfalls of being able to then monkey around with the sentinel.

As a note, the stdlib errors is not const-compatible, so. 😐

@davecheney
Copy link
Member

I'm sorry I haven't replied before now.
I'm going to close this issue as there is nothing to do here; this package isn't what you what, its designed in a way that is incompatible with your requirements.

davecheney added a commit that referenced this issue Jan 5, 2019
Fixes #160
Fixes #107

Signed-off-by: Dave Cheney <[email protected]>
davecheney added a commit that referenced this issue Jan 5, 2019
Fixes #160
Fixes #107

Signed-off-by: Dave Cheney <[email protected]>
@davecheney davecheney reopened this Jan 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants