[bb88]

This is how I understood the use for panics:

https://stackoverflow.com/questions/44504354/should-i-use-pa...

    > You should assume that a panic will be immediately fatal, for 
    > the entire program, or at the very least for the current 
    > goroutine. Ask yourself "when this happens, should
    > the application immediately crash?" If yes, use a panic; 
    > otherwise, use an error.

In Java, say, exceptions are the standard for raising a normal error. A class of those exceptions are runtime errors which are equivalent of "panics". Yes you can handle them, but they denote a problem with the program that can't be solved by the interpreter (divide by zero error, etc)

[ithkuil]

If want (and if it makes sense) you can use panics as a control flow mechanism to quickly bubble up errors inside your implementations.

See an example in the standard library itself: https://golang.org/src/encoding/json/encode.go, line 295

What's frowned upon is leaking this out of your package's interface/contract.

[bb88]

Then it strikes me kind of like C++ exceptions. They have them, and it's kinda supported, and there are certain things you shouldn't do with them, so everyone just uses return codes.

Java/Python encourage the use of exceptions as returning error conditions, rather than return error codes.