search

goodeggs / librato-node

A Node.js client for Librato (http://librato.com/)
MIT License
37 stars 26 forks source link

Ditch EventEmitter API #33

Open adborden opened 9 years ago

adborden commented 9 years ago

We don't really document it, but librato-node extends EventEmitter and emits errors in addition to calling the callback.

This is a bit strange because:

  1. It's not documented.
  2. You have to handle the error twice, or at least setup two handlers.

There is only one place where we're actually using emit. Should we just drop the EventEmitter API?

kevinburkeshyp commented 9 years ago

I'm confused by "handle the error twice", at least if all you are doing is using start, stop and increment() etc, flushing happens in the background and you're not handling it; the only way to handle errors in that case would be with .on('error')

I'd prefer if the worker didn't crash when Librato errored, or for the .on('error') procedure to be highlighted in the README in big red letters.

adborden commented 9 years ago

Good point. I was thinking in the manual flush case, you get the error from the callback and the emitter.

If we decide to keep it, I agree that we should document it.

icodeforlove commented 9 years ago

This one just bit me, there really needs to be documentation on this. Do i understand this correctly, if i have a 

liberato.on('error', function() {});

I will no longer have uncaught errors when there are network issues?

adborden commented 9 years ago

Yeah, that's right. I just added this to the readme #46

bobzoller commented 9 years ago

thanks @adborden!

On Sun, Aug 9, 2015 at 7:19 PM, Aaron Borden notifications@github.com wrote:

Yeah, that's right. I just added this to the readme #46 https://github.com/goodeggs/librato-node/pull/46

— Reply to this email directly or view it on GitHub https://github.com/goodeggs/librato-node/issues/33#issuecomment-129279894 .

timborden commented 9 years ago

Bit me too....thanks @adborden for adding to the docs