Handle exceptions thrown by cache reads

[jordanholt]

Description

Handle exceptions thrown by attempted async calls to store.set().

Motivation and Context

Prevent cache engine issues resulting in an unhandled exception bubbling up to an EUNKNOWN error.

How Has This Been Tested?

Manual testing.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[crosslandwa]

OBSERVATION: I think this needs documenting (via tests and/or the README.md)

This implementation means if the supplied cache implementation is "broken" the library will never actually try to make outgoing requests - I agree with this behaviour, but feels its a design decision that should be documented

edit
on further consideration, i've realised this doesn't change the above behaviour (it was already throwing/Promise.rejecting if the supplied cache is faulty) - its now giving an easier to reason about error.

Changing to an APPROVE (though some unit tests in caching.test.ts might still be worthwhile)

[jordanholt]

👍 I'll add some more unit tests, that file is the only one with <75% branch coverage.

[ben-whitfield]

LGTM