Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error-reporting: fix up sample #53

Closed
broady opened this issue May 17, 2016 · 5 comments
Closed

error-reporting: fix up sample #53

broady opened this issue May 17, 2016 · 5 comments
Assignees
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: enhancement

Comments

@broady
Copy link
Contributor

broady commented May 17, 2016

The whole divide by zero thing is weird. Just use panic or remove the panic/defer code completely.

@odeke-em
Copy link
Contributor

At @broady you mean this

// Handler for the incoming requests.
func demoHandler(w http.ResponseWriter, r *http.Request) {
// How to handle a panic.
defer func() {
if e := recover(); e != nil {
stack := make([]byte, 1<<16)
stackSize := runtime.Stack(stack, true)
report(string(stack[:stackSize]), r)
}
}()
// Panic is triggered.
x := 0
log.Println(100500 / x)
}

IMHO it suffices and doesn't need removing to use panic, because it shows the user how to capture the stacktrace for their bug report. What do you think?

@broady
Copy link
Contributor Author

broady commented Aug 23, 2017

Yep, that one.

I guess it's fine, but I don't fully understand the usage of error reporting for Go. Do we really want people to only use it for panics?

/cc @rakyll

@ghost
Copy link

ghost commented Mar 27, 2018

There's a package that may simplify the code a little; github.com/pkg/errors
Thus

import (
    "github.com/pkg/errors"
)
... 
// Handler for the incoming requests. 
func demoHandler(w http.ResponseWriter, r *http.Request) { 
 	err := errors.Error("Runtime Issue with demoHandler")
        if err != nil {
            report(err, r)
        }
}
func report(err Error, r *http.Request) {
        ...
        "stacktrace": errors.Errorf("%+v", err)
        ...
}

I'm not sure, though, how helpful stack traces are as Rob Pike has written that errors should be given context before before bubbled up the stack or dealt with without causing the system to fall over. Using the errors pkg we could now wrap one error context within another potentially creating a much nicer and helpful error message rather than a stack trace (remembers screens full of java stack traces....!) Just my two pennies.

@tbpg
Copy link
Contributor

tbpg commented Jun 11, 2019

@broady @odeke-em I haven't seen any feedback about this. Do you still have ideas about how to improve it, or should we close this?

@Brotherhod Thanks for the link and example. I'd prefer to avoid using any additional external dependencies.

@JustinBeckwith JustinBeckwith added triage me I really want to be triaged. 🚨 This issue needs some love. labels Oct 3, 2019
@tbpg tbpg added type: enhancement priority: p2 Moderately-important priority. Fix may not be included in next release. labels Oct 3, 2019
@tbpg
Copy link
Contributor

tbpg commented Oct 3, 2019

Declaring issue bankruptcy on this. Feel free to reopen if you want to fix it.

@tbpg tbpg closed this as completed Oct 3, 2019
@yoshi-automation yoshi-automation removed 🚨 This issue needs some love. triage me I really want to be triaged. labels Apr 6, 2020
@tbpg tbpg self-assigned this May 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: enhancement
Projects
None yet
Development

No branches or pull requests

5 participants