Granted, explicit error handling is a good idea. At some level, it depends on the personal style. Perhaps I'm missing something, but I like to write a ton of as

Granted, explicit error handling is a good idea. At some level, it depends on the personal style. Perhaps I'm missing something, but I like to write a ton of assertions to validate code invariants. On assertion failure, which obviously never happens as I write perfect code that never violates invariants, all I want to happen is 'write the error in the logs and return 50x'. I suppose panic/recover is the way to go, but I have the impression they are shunned by the community and not recommended by Golang official docs. https://golang.org/doc/faq#assertions https://golang.org/doc/faq#assertions > Why does Go not have assertions? > Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code. > We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.