> > we should treat these cases as errors > Looking at the fields listed in the FLIP, I'd agree with this argument. And based on this, shouldn't we fail the request with e.g., a status code 500, rather than responding with a fallback value silently?
Best, Xintong On Tue, Jul 25, 2023 at 12:22 AM Jing Ge <j...@ververica.com.invalid> wrote: > 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 > > > > >
