improve clarity when member is not exist

[chx9]

this pr aims to fix one of the issues from Redis Triage https://github.com/orgs/redis/projects/6?pane=issue&itemId=69775417&issue=redis%7Credis%7C13350 it has been more than 1 year since this issue brought up

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 80.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 70.96%. Comparing base (44dafba) to head (9b27f21). Report is 99 commits behind head on unstable.

Files with missing lines	Patch %	Lines
src/geo.c	80.00%	2 Missing :warning:

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1943      +/-   ##
============================================
- Coverage     70.99%   70.96%   -0.04%     
============================================
  Files           123      123              
  Lines         65769    66136     +367     
============================================
+ Hits          46693    46933     +240     
- Misses        19076    19203     +127     

Files with missing lines	Coverage Δ
src/geo.c	93.15% <80.00%> (-0.43%)	:arrow_down:

... and 43 files with indirect coverage changes

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Fusl]

longLatFromMember can also return C_ERR if geohashDecodeToLongLatType returns a decoding error while the member did exist. Should we maybe differentiate those cases or just return member %s does not exist or failed to decode?

[madolson]

longLatFromMember can also return C_ERR if geohashDecodeToLongLatType returns a decoding error while the member did exist. Should we maybe differentiate those cases or just return member %s does not exist or failed to decode?

Ideally yes. It would be nice to differentiate the member be missing from some type of corruption.

[chx9]

longLatFromMember can also return C_ERR if geohashDecodeToLongLatType returns a decoding error while the member did exist. Should we maybe differentiate those cases or just return member %s does not exist or failed to decode?

Ideally yes. It would be nice to differentiate the member be missing from some type of corruption.

agree, i added error infomation for each case.