On Tue, 12 Jan 2016 11:30:08 -0800 (PST) thebrokentoaster@gmail.com wrote:

I agree with Paul, that they are fine to use in certain situation,
but certainly not in all situations. And most certainly, the panic
should never cross the package boundary.

However, I do feel like there are conflicting opinions on this. Dave
Cheney, can you clarify if your position on this? Are you saying that
it is never idiomatic to use panics? Or are there certain rare
scenarios where it is acceptable to use?

Interestingly, the Go proverbs mentions "don't panic" as the last
proverb, but in the video linked at the bottom, Rob Pike ends his
talk after "documentation is for the users", so I'm not exactly sure
where that proverb came from.

Also, the Defer, Panic, and Recover blog post
<http://blog.golang.org/defer-panic-and-recover> explicitly mentions
encoding/json as a real-world example of panic/recover. This seems to
indicate that it is fine to use panics in these situations.
While reading the post which started this discussion [1] I, for one, got
the feeling that the OP habitually used panic() for "normal" error
reporting and wondered why they did not see this pattern used much in
the other people's code.

Let's cite that post:
I like how it lets me prepend the function name, which makes
diagnosis easier when multiple layers of functions are traversed. A
poor's man stacktrace, of sorts. Is this a bad pattern?
I'd say this usage is a clear anti-pattern:

* If one wants to convey much information about the error, the name of
   the function it occured in has (in most cases in my opinion) zero
   relevance. The operational context has -- just look at os.PathError
   as a good example: it records what operation having been taken, and
   on which item, and why it failed. Does it matter how exactly the
   function actually trapped the error was named? I highly doubt so.

* When debugging, I think it's okay to just temporary panic() in certain
   key places -- and that will automatically provide the programmer with
   the stack trace, function names, file names and line numbers.

   That is, if you need "a poor man's stack trace" just get a rich man's
   stack trace so to say. ;-)

So my take is that Dave got impressions close to mine and warned about
abusing the feature.

1. https://groups.google.com/d/msg/golang-nuts/D3Akaa-syuw/1PVY2E8aEgAJ

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 12 | next ›
Discussion Overview
groupgolang-nuts @
postedJan 10, '16 at 12:25a
activeJan 12, '16 at 9:56p



site design / logo © 2021 Grokbase