We might consider using 0 as null for values that never return 0. But null is still not equal to 0 and it will be very difficult to let every contributor in this community follow this rule, especially for future unknown APIs, which means there will be some cases that still need null. Personally, I would choose accuracy over convenience and consistency over convenience. Therefore, null is recommended.
Best regards, Jing On Mon, Jul 24, 2023 at 11:48 PM Chesnay Schepler <ches...@apache.org> wrote: > The downside to null is that it again forces users to handle this case > themselves. > > The reality is that there is no good default value. > > Ideally we fix all cases where we return such values, such that the > fallback to 0 isn't even used. > Arguably the same could be said for null, but I'd think that 0 is less > of a surprise. > > On 24/07/2023 17:21, Gyula Fóra wrote: > > I agree that it's a bit strange to have 0 as a fallback value because it > > can also naturally occur for many metrics. > > If we want to omit the value null would be probably better as Matthias > > suggested. > > > > Gyula > > > > On Mon, Jul 24, 2023 at 4:02 PM Matthias Pohl > > <matthias.p...@aiven.io.invalid> wrote: > > > >> What was the reason you decided to go for 0 as the fallback value > instead > >> of null? Wouldn't that be a more reasonable value for error cases? > >> > >> On Mon, Jul 24, 2023 at 12:51 PM Chesnay Schepler <ches...@apache.org> > >> wrote: > >> > >>> There are a number of cases where the REST API can return infinity or > >>> NaN for certain double fields. > >>> > >>> This is problematic because the JSON spec does not allow such values, > >>> and tooling working against that spec may run into issues when > >>> encountering such a value. > >>> > >>> Specifically we've seen this become an issue in clients generated from > >>> the OpenAPI spec. > >>> > >>> > >>> > >>> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263425797 > >
