Panics can be incredibly useful. I use them in HTTP services to simplify returning error JSON objects to the consumer. In general I'm a bit surprised about al

Panics can be incredibly useful. I use them in HTTP services to simplify returning error JSON objects to the consumer. In general I'm a bit surprised about all the hate(I say hate because of how people react to it and react to suggestions for how to better work with it) the error system gets. I find that creative use of error/panic can usually scratch my "this is too much error handling code" itch when it flares up. As long as it's documented in the API I agree that unique public error handling strategies are not all bad. Interestingly I write a lot of C#, which of course has try/catch/finally, and I find that if you are doing it properly you have many levels of handling and a strategy involved at the different levels for what should done when. I find that many people write TERRIBLE error handling. There may be try/catch sprinkled around but there will be no strategy to it with edge-cases and improper handling abound(masked exceptions, finaly's throwing new, unrelated exceptions, etc). I personally find the amount of effort required into developing and executing a robust error handling strategy to be about the same between C# and Go. That's not to say that I don't sometimes wish Go had C#'s error handling( ;) ), but I realize they are different beasts with different masters.