Ditch EventEmitter API

[adborden]

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]

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]

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]

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]

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

[bobzoller]

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
#46

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

[timborden]

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