Becket, comments inline. On Fri, Sep 9, 2016 at 6:55 PM, Becket Qin <becket....@gmail.com> wrote:
> Completely agree that we should have a consistent representation of > something missing/unknown in the code. > > My understanding of the convention is that -1 means "not > available"/"unknown". For example, when producer request failed, the offset > we used in the callback is -1. And Message.NoTimestamp is also -1. ProducerRecord uses a nullable timestamp instead of Record.NO_TIMESTAMP to indicate a missing value though. That was the example in my original message. Using -1 > instead of null has at least two benefits. > 1) it works for primitive type as well as classes. > This isn't a benefit outside of very specific use-cases (were the cost of boxing is a problem). The wrapper classes can be used, after all. The downsides of using -1 is that the type system doesn't help you (there's a reason why they're called magic values). If you see a `java.lang.Long`, you have a hint that `null` is a valid value. The other problem with a -1 for a timestamp is that you may do nonsensical comparisons against it without error. When using `null`, it will fail-fast with a NPE so that you can fix it (even better would be to get compile-time errors, but let's leave that out of this discussion for now). > 2) it is easy to send via wire protocols > I think it's important to distinguish what we do in the wire protocols (which may be more low-level) with what we do in user facing APIs (where usability and safety are very important). Ismael
