qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Electron/Amqp MessageAnnotations in Golang
Date Fri, 10 Nov 2017 18:09:28 GMT
On Fri, Nov 10, 2017 at 8:28 AM, Jiri Danek < jdanek@redhat.com > wrote:

> On Fri, Nov 10, 2017 at 1:10 PM, Alessio Gottardo
> <tappoz84@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message