TypeError: value.getLowBits is not a function

[erodriguezds]

TypeError: value.getLowBits is not a function

[wbt]

It looks like the core issue here may be in the bson library, imported via mongodb.
Supposing the error is caught, what do you think should happen in the catch block?

[erodriguezds]

@wbt, thanks for your prompt reply

As I proposed in the original post, It would be nice to, maybe (it's just an idea) have an "onError" option, or "onUnhandledError", you pick the name, which could be a callback provided by the user, and, on any error that may occur with the uderlying mongodb connection, invoke this callback provided by the user, and let the user decide what to do with this broken/failed log... and, if no callback is provided, then: do nothing, but at least catch the error, and don't let the application crash.

[wbt]

@erodriguezds Emitting an event seems sensible, but I think a crash in the no-listener case is reasonable because we don't want folks thinking their logs are working just fine only to find out after it really matters that they weren't.

[erodriguezds]

@wbt , I'm glad you guys find the error handler sensible... hope you can work on this as a "feature request".

Regarding the crash in a no-error-handler case, I think it's quite arguable... keep in mind that this library is just a logging "transport"... the user may use other transports as well... and this is actually our case. We also use a Slack-webhook transport to receive critical messages.... so, imagine the slack service is down.. do you think the slack transport should crash my app because there's a problem with Slack? My other transports are still working!

[wbt]

@wbt , I'm glad you guys find the error handler sensible... hope you can work on this as a "feature request".

I don't currently use the MongoDB transport at all, so I'm not going to be working on that anytime soon, and I'm not even the best choice of person for reviewing/testing a proposal from someone else (here's to hoping another maintainer might raise their hand to take that review on!). Winston currently has zero budget for maintainers and PRs for both bugfixes and new features come from the community.

In the no-error-handler case, I think your arrangement with multiple handlers is not the norm, but it does seem reasonable to limit the app-crash outcome to a situation where all transports (or all transports above a certain log level) have errored out.