Closed Giners closed 6 years ago
You're quite right - I hadn't thought about those throws from dependencies. The neatest approach to this these days is probably just to mark our public, promise-returning APIs as async
, that way they're guaranteed to return a Promise
and any throw
inside the function will be converted to a rejection.
Unfortunately this is a (very minor) breaking change, since anyone actually expecting a synchronous exception will now see different behaviour. It'll be in the next release though.
Functions that you have documented as returning a promise (e.g.
queryRadius()
) also throw exceptions as well. This is an anti-pattern in terms of JavaScript promise-based functions. This is especially problematic when working with thedynamodb-geo.js
APIs outside of the context of anasync
function. Here is an example/repo:This will cause the exception
Error: [DecimalError] Invalid argument: undefined
to be thrown which is reasonable since I provided bad input forCenterPoint
. Yet the thrown exception circumvents all of my error handling logic (i.e. function passed to thecatch()
method) that I expect to run when the promise is rejected. The problem further compounds itself if I was expecting to delegate to another construct/module to perform additional async work as a result of a rejected promise (e.g. performing an asyncsetState()
call for a React component).The problem can be resolved by wrapping APIs you have documented as returning a promise with a
try/catch
. For example:Other notes:
dynamodb-geo.js
exposes for consumption also have this problem/anti-patterndynamodb-geo
@ version 0.3.4. If this was fixed in version 0.4.0 then sorry for the noise.Just wanted to finish off by saying great work on
dynamodb-geo.js
@rh389! It has proved very valuable. :smile: