no error handling

[matthewberryman]

no error handling on gnip API errors e.g.

2017-04-30T00:16:31.730Z - error: uncaughtException: Unable to fetch rules. Requ
est failed with status code: 403, Error: Unable to fetch rules. Request failed with status code: 403
    at Request._callback (/home/ubuntu/cognicity-reports/gnip-powertrack/node_modules/gnip/lib/rules.js:93:7)
    at Request.self.callback (/home/ubuntu/cognicity-reports/gnip-powertrack/node_modules/request/main.js:120:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:191:7)
    at Request.<anonymous> (/home/ubuntu/cognicity-reports/gnip-powertrack/node_modules/request/main.js:555:16)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)
    at IncomingMessage.<anonymous> (/home/ubuntu/cognicity-reports/gnip-powertrack/node_modules/request/main.js:517:14)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
2017-04-30T00:16:31.730Z - error: Fatal error: Application shutting down
2017-04-30T00:16:31.730Z - info: Exiting with status 1

[tomasholderness]

It seems that Gnip's response of 403 broke the gnip module (external node module), our app interprets this as a Fatal error (as no rules = no data) and shuts down. Should we have an alternative strategy (e.g. attempt to reconnect)?

[matthewberryman]

In the case of 403 and the others with exception of 429 and 503 (see reference at http://support.gnip.com/apis/powertrack/api_reference.html ) it looks like they would need human intervention to resolve; so in that case we should report somehow—I propose using an SNS topic in the reports main module, a reference to an object with methods for this should be passed to and callable from the submodules—and the gnip module should gracefully stop, leaving other submodules running. Thoughts?