3 ms·

The stdlib's compress/bzip2 internally does the same sort of thing where you do a bunch of operations and then check for errors: http://golang.org/src/compress/

The stdlib's compress/bzip2 internally does the same sort of thing where you do a bunch of operations and then check for errors: http://golang.org/src/compress/bzip2/bit_reader.go#L12 http://golang.org/src/compress/bzip2/bit_reader.go#L12 And regexp uses panics to propagate parse errors up the stack internally, and that's even described in Effective Go: http://golang.org/doc/effective_go.html#recover http://golang.org/doc/effective_go.html#recover In both cases an error value is returned to the package user. In general, I think you should feel freer do abnormal things that suit your situation within a package as opposed to across API boundaries. The standard ways of doing things should still be preferred when it's not too costly: the standards are what they are for a reason (even if the tradeoffs they represent are more appealing in some situations than others), it's easier to read code that's written in the way everyone's used to, and standards help keep you from spending time bikeshedding unimportant details. But the surface area of your package is the first thing users will have to learn, and what you have to keep in your head whenever maintaining code that uses your package--that's what it's most important to make clean and normal-looking and consistent. I know the post talks about using an unusual error-handling pattern in an API, and you can do that sometimes, too. Just trying to make a separate point--when you're thinking about doing unusual stuff, keep in mind there's a big difference between an unusual implementation and an unusual API.

Rapzid 12y ago
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.

Rapzid 12y ago

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.