Swallowing errors?

[aaronyo]

I was considering this library, but it looks like you swallow errors after console logging them.

    try {
      await handler(...args)
    } catch (err) {
      console.error(err)
    }

If my async operation throws an error, I'd want to be handling it myself, and if I forgot to handle it (or didn't want to), I'd rather setIntervalAsync rethrow than log and swallow.

[aaronyo]

After considering a bit more, instead of crashing setIntervalAsync (which does not happen with setInterval), I think what I'd want is to get an "Uncaught" or "Unhandled rejection" error logged by the runtime. In other words, don't catch the error and let the browser or nodejs do whatever it does with unhandled promise rejections.

What do you think?

[ealmansi]

@aaronyo thanks for your input, it is very much welcome.

One of the main goals for this library is to be API-compatible with setInterval as much as possible, and the issue you point out is indeed a divergence from the original API. I think a fix would be possible by simply refactoring the code after that try-catch into some function and then:

try {
  await handler(...args);
} catch (err) {
  someFn(...);
  throw err;
}
someFn(...);

However, we'd need to evaluate whether that works on all environments and whether the same fix is available for other flavors. Also, I'd be somewhat hesitant on pulling in these changes, since it may negatively affect production code out there using this library.

Will look into this more thoughtfully, further feedback is welcome.