grpc / grpc-dart

The Dart language implementation of gRPC.
https://pub.dev/packages/grpc
Apache License 2.0
853 stars 268 forks source link

Nullable ServiceCall properties #462

Open enyo opened 3 years ago

enyo commented 3 years ago

Is there a reason for the clientMetadata, headers, and trailers to be nullable in https://github.com/grpc/grpc-dart/blob/master/lib/src/server/call.dart#L22 ?

Before migrating to null safety, I have always assumed that they were set (and if there were none, the Maps would be empty).

Is this a mistake or should my code handle the scenario when they are null? And if it's on purpose: when can they actually be null?

grpc : 3.0.0

mraleph commented 3 years ago

This is an interesting question. Underlying headers and trailers are nullable because implementation nulls them out when they are are not longer needed / do not affect subsequent flow of the program (e.g. once headers are sent corresponding field is nulled out). clientMetadata is nullable because the field only becomes not-null once we received metadata from the client.

Theoretically if you only interact ServiceCall in interceptors then indeed these fields would be non-null there.

enyo commented 3 years ago

Ok I see. So it's more of an implementation detail then? In that case, would it make sense to add private fields for that, that are nullable, and wrap them with non-nullable getters which throw an exception if accessed when it's null?

Edit: at least for the headers and trailers

mraleph commented 3 years ago

We could do that. They are already wrapped in the getters. It would be best if we were to restructure APIs in such a way that error could never occur though