On Fri, Nov 10, 2017 at 8:28 AM, Jiri Danek < jda...@redhat.com > wrote:
> On Fri, Nov 10, 2017 at 1:10 PM, Alessio Gottardo > <tappo...@yahoo.it.invalid > > wrote: > > > > Out of curiosity is there a specific reason for `panic`ing in the > > `default` case instead of returning an `error`?I just became aware of > this > > `recover` mechanism in go to handle a runtime `panic` thrown somewhere > > else, but that's going to make the code quite a bit more complicated. I > was > > wondering if it would have been easier to return an error to whoever uses > > the `amqp` go wrapper, but I see that could have quite of an impact on > the > > codebase as it is at the moment. > > Thank you for the fix.Alessio > > > > I was thinking the same thing.I read somewhere that `panic`s in Go are > intended to not cross library boundaries (and not be part of the API). > - Exactly - the panics do not cross library boundaries (unless there's a bug) and are not part of the API. You'll see that the exported Marshal and Unmarshal functions recover from the panic and return an error instead. This is a trick I copied from some of the standard libraries that do similar marshal/unmarshal (e.g. xml and json) - exception-like panic/recover inside the package, but return error at the boundaries. Nowadays I have gotten to appreciate Go's very explicit error return style, so I don't use that trick much anymore, but in this particular package it works well so I left it there.
