Should check for error code from h3Line call about h3-js

[nrabinowitz]

I had a related conversation with @isaacbrodsky here: uber/h3-java#36

You are correct, I should check the output of h3Line for completeness (I'm updating the title of this issue to reflect that). But with the current implementation of h3Line, it is (almost certainly) impossible to get a non-zero exit code here IFF you got a a value > 0 from h3LineSize. Both functions just delegate immediately to h3Distance under the hood.

So while you're right that we should check, the error condition here is (almost certainly) unreachable, and is unlikely to be the source of your bug. I think it's more likely you're running into undefined output due to whatever is behind uber/h3#184.

[dfellis]

Hmm... So it looks like Isaac is planning to dig into that issue, but do you have any proposal right now? Maybe I should just confirm that 90+% of the runs succeed? (That would still have very intermittent failures if the random number generator ever does more than 10% lines through pentagons.)

[nrabinowitz]

Not sure. Possibilities here:

• Keep your current test with a threshold, as you note, and try to drop it later
• Implement separate property-based tests, as we do here: https://github.com/uber/h3-js/blob/master/test/h3core.spec.js#L1201 - these should work regardless of h3-js issues (though I think the failure cases might fail here too, if they're in the underlying lib)

I don't necessarily think that asserting identical output here is a big issue, since we explicitly don't guarantee stable output across versions - there are multiple "correct" answers here, so the important concern is guaranteeing the properties of the output, not necessarily the consistency of the output.

[dfellis]

Well, I am trying to guarantee that the major and minor version numbers for h3-node match those of h3-js so it can be a drop-in replacement (assuming no error condition reached) for anyone wanting a perf boost on Node apps.

Let me think about it a bit more. The random-but-valid input approach was nice as a kind of fuzzing, as well (which is how I found this discrepancy in the first place).

[nrabinowitz]

This issue should be covered by the new error handling in #139