It's not uncommon to endless-loop until something goes wrong in such a case (see, for example, http.Serve <https://godoc.org/net/http#Serve>). Just return an error from Client.Start as suggested and then catch that in main and log.Fatal there. If a user of your library needs to do more code, they'll have to wrap the concurrent error handling code themselves.
I wouldn't expose channels in an API if at all preventable. They usually open up questions that the compiler can't check and that, if answered correctly, will result in mostly the equivalent amount of code to just wrapping a synchronous API anyway. For example: Does the channel need to be buffered or not? What would a good channel size be? What happens if the reader from the channel is slow, do values get dropped, or queued, or does the sender block? If the latter, is there a timeout? On Wed, Feb 8, 2017 at 11:04 AM, Francis Chuang <f21.gro...@gmail.com> wrote: > I made a mistake with my example. c.Start() needs to be a separate go > routine because it is an infinite loop waiting for messages: go c.Start(). > > In that case, I am guessing an errors channel would be the best? > > Cheers, > Francis > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
