3 ms·
What? You're gonna need to link a source for that, because everything I've ever read is that panics are for catastrophic failure and should not be used for rout
by jniedrauer 7y ago
What? You're gonna need to link a source for that, because everything I've ever read is that panics are for catastrophic failure and should not be used for routine error handling.
Rob Pike has this to say:
Our proposal instead ties the handling to a function - a dying function - and thereby, deliberately, makes it harder to use. We want you think of panics as, well, panics! They are rare events that very few functions should ever need to think about. If you want to protect your code, one or two recover calls should do it for the whole program. If you're already worrying about discriminating different kinds of panics, you've lost sight of the ball.
- BlueDingo 7y agoUnless edited, I don't think that's what GP said. Panics are the way to get stacktraces, not the way to routinely handle errors. Your top level comment about 403 errors made me assume you did not know about panic. Obviously your particular situation may have prevented it but I've always built Go programs from source (not linking binaries) which means I could always panic whenever I needed a stack trace.
- omegabravo 7y agoPanics provide stacktraces, but are not the way to get stack traces. runtime/debug has the API to generate stacktraces. github.com/pkg/errors is the ubiquitous library for seamlessly including stacktraces in errors