gin

only time where you really, genuinely would need to parse strings is if you caught panics from the language runtime, which are actually just strings. However, this is unsupported, and the current Go HEAD actually just changed the format of an index out of bounds panic, so it would be very unwise to do this. Examples of libraries that provide richer errors that satisfy the standard error interface: - go-pg: https://godoc.org/github.com/go-pg/pg#Error - elastigo: https://godoc.org/github.com/mattbaird/elastigo/lib#ESError - redigo: https://godoc.org/github.com/gomodule/redigo/redis#Error (it's a string because the underlying protocol uses error strings.) - gin: https://godoc.org/github.com/gin-gonic/gin#Error The first three I picked because I used them, but the last one was fun. I just found one of the top Go libraries on GitHub explore and checked to see if they had a rich error type in their library, and they did. It's definitely common practice. So yeah, you shouldn't be parsing error strings. >- if .... else boilerplate Yes that's the repetition problem that there's proposals to fix, but if that's the worst problem I still find it less annoying than needing this, which requires at least two new scopes: try { doThing(param[0]); } catch(e IOException) { Log.Warning(e.message); return; } catch(e ApiException) { throw new InvalidParameterException(String.Format("Invalid parameter: {}", param[0]), e); } Or, even worse, not needing anything at all. // Compiles // No lint warning // Sometimes correct! doThing(param[0]); ...Which is not always even bad practice because you may very well want the parent to catch those. But without comments, there's no way for the users of your function to know what to catch unless they inspect the function. Without inspecting every possible codepath, it is impossible to know which errors are inadvertently not handled, and sometimes it is difficult to tell how a given error will be handled. The correct thing to do in Go is almost always some variation of this, which is pretty simple: err := doThing(param[0]) if err != nil { return err } But these blocks are not invisible, and sometimes it will occur to you while writing it out that it isn't right for a given call site. So you can make it more complicated: err := doThing(param[0]) if err == io.EOF { log.Printf("While doing thing: %v", err) return err } else if err != nil { return errors.Wrap(err, fmt.Sprintf("invalid parameter: %v", param[0])) } Go doesn't force correct error handling, but it makes incorrect error handling more obvious, and it certainly makes you aware of error paths. >- Underscore everywhere to silence them You shouldn't silence them, unless maybe if you are writing example code. But a lot of examples on the web will just have correct error handling, which seems like a win/win to me. >- Abuse from panic, aka exceptions in disguise That's just bad code. You even said 'abuse' yourself. You can call them exceptions in disguise, but they're really not. This thinking basically implies all error handling that unwinds the stack is “exceptions.” If they were exceptions, presumably you'd love Go error handling, because it has exceptions. Panic is a lot more limited, and generally good software will only catch panics in a couple types of circumstances: - At API boundary edges when dealing with an API that nests deeply. In this case, you can recover but panic if the error was not an API error. This would allow a library to avoid passing the error value around when the only logical thing to do with the error value is to pass it back to the library user; A good example would be a parser. - When trying to isolate a failure, for example to prevent one HTTP request from taking down an entire HTTP server. >If you want error handling without exception's guesswork, there are checked exceptions (used for the first time in CLU 1975), and result types (used for the first in ML in 1973) Does your language of choice actually support checked exceptions? C#, Python, JavaScript don't. Only modern language I am aware of that does off-hand is Java, and I don't think very much at all uses it, because it is even more annoying than Go error handling. >Just because they have a very good career, it doesn't make them always right. No, but it would be awfully strange if they learned nothing from that experience, which is kind of what you implied. >I tend to think for myself and not from opinions of others. This is just an empty platitude. I never claimed that my opinion of Go being good was due to the background of Rob Pike or Bell Labers in general, just pointing out that the point of 'I programmed in the 80s and 90s' seems kind of odd given the background of the language designers. Go is very opinionated, but I happen to like those opinions, genuinely.