The error handling in gmapsdistance only covers about half of cases. It seems to depend on results$error_message for the rest of them, but as Google points out, "This field is not guaranteed to be always present, and its content is subject to change."
One easily reproducible example is:
gmapsdistance(c("1600+Pennsylvania+Ave+NW,+Washington,+DC+20500"), c("1600+Pennsylvania+Ave+NW,+Washington,+DC+20500"), mode="driving")
which in the latest github version, returns:
$Time
[1] 0
$Distance
[1] 0
$Status
[1] "OK"
even though I'm sure the response contained the top-level status "INVALID_REQUEST", which should have been reported to the user in some way. (The problem with this request being the commas: replacing them with "%2C" makes the call work fine).
Other top-level status codes that need handling include MAX_ELEMENTS_EXCEEDED, OVER_DAILY_LIMIT, and MAX_ROUTE_LENGTH_EXCEEDED (and possibly UNKNOWN_ERROR, although according to the site that might just call for another attempt at the same request). They don't necessarily need explicit handling, a simple "if not OK" check that prints the returned status (and possibly stops) would be fine, or they could be returned as part of the result (which would make sense for INVALID_REQUEST and MAX_ROUTE_LENGTH_EXCEEDED). MAX_ROUTE_LENGTH_EXCEEDED might also need handling at the element-level.
*MAX_ELEMENTS_EXCEEDED shouldn't practically be possible with the single-origin, single-destination requests being used at the moment, but in case the code ever does implement request batching, generic handling for it would be nice.
The error handling in gmapsdistance only covers about half of cases. It seems to depend on results$error_message for the rest of them, but as Google points out, "This field is not guaranteed to be always present, and its content is subject to change."
One easily reproducible example is:
gmapsdistance(c("1600+Pennsylvania+Ave+NW,+Washington,+DC+20500"), c("1600+Pennsylvania+Ave+NW,+Washington,+DC+20500"), mode="driving")which in the latest github version, returns:even though I'm sure the response contained the top-level status "INVALID_REQUEST", which should have been reported to the user in some way. (The problem with this request being the commas: replacing them with "%2C" makes the call work fine).
Other top-level status codes that need handling include MAX_ELEMENTS_EXCEEDED, OVER_DAILY_LIMIT, and MAX_ROUTE_LENGTH_EXCEEDED (and possibly UNKNOWN_ERROR, although according to the site that might just call for another attempt at the same request). They don't necessarily need explicit handling, a simple "if not OK" check that prints the returned status (and possibly stops) would be fine, or they could be returned as part of the result (which would make sense for INVALID_REQUEST and MAX_ROUTE_LENGTH_EXCEEDED). MAX_ROUTE_LENGTH_EXCEEDED might also need handling at the element-level. *MAX_ELEMENTS_EXCEEDED shouldn't practically be possible with the single-origin, single-destination requests being used at the moment, but in case the code ever does implement request batching, generic handling for it would be nice.