Propagate Connection Exceptions about graphyte

[benhoyt]

Thanks @barrycarey. It's been a while now, but the idea was to not let them bubble up, because you don't want an intermittent failure in recording metrics to blow up your API for users (though I guess you could argue that metrics being broken is a severe problem so that's okay).

If you don't have log_sends turned on, sender.send_socket = sender.send_message is a shortcut to subclassing:

>>> sender = graphyte.Sender('localhost')
>>> sender.send('metric', 42)
error sending message b'metric 42 1632375414\n': [Errno 111] Connection refused
>>> sender.send_socket = sender.send_message
>>> sender.send('metric', 42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ben/h/graphyte/graphyte.py", line 115, in send
    self.send_socket(message)
  File "/home/ben/h/graphyte/graphyte.py", line 124, in send_message
    sock = socket.create_connection((self.host, self.port), self.timeout)
  File "/usr/lib/python3.8/socket.py", line 808, in create_connection
    raise err
  File "/usr/lib/python3.8/socket.py", line 796, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

Maybe we could simply document this? Or what "API" did you have in mind? Something like a raise_errors argument to Sender() that defaults to False?

[barrycarey]

I didn't think of reassigning send_socket(). That's certainly an easier solution to sub-classing.

My use case might be a bit niche but I always feel like giving client code the ability choose how to deal with errors is best. In my case I have a pool of metric services I'm sending to. If one of those services fail I need to be able to have logic to determine how to react (cool down, drop from pool, ect).

I like the idea of having na arg to control it. One downside I can see is if using the background thread it would cause the thread to die. That would need to be documented.

If you're okay with using an arg I can put together a PR.

[benhoyt]

Thanks. It seems your use case is exactly when I'd advocate creating a subclass. And you'd override send_message to be the thing that deals with your pool of metric servers and handle appropriately. That would work for interval / background thread mode too.

That said, if you want to go ahead with this, I don't mind adding it, to give the user more control. If you do go ahead and submit a PR, let's call the new parameter raise_send_errors to be explicit (default False). We'll need a test for it. Good point regarding what to do in the background thread case. I think probably Sender.__init__ should simply disallow that case and raise a ValueError if you provide raise_send_errors and interval is not None.

[barrycarey]

I just submitted PR #18 before I realized you responded here.

During init I checked if interval was provided. If it was and raise_send_errors it true, it logs a message and sets raise_send_errors to false. I can modify to throw in exception if that's what you prefer.

[benhoyt]

Merged your PR, thanks!