Open enyo opened 3 years ago
This is an interesting question. Underlying headers
and trailers
are nullable because implementation null
s 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 null
ed 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.
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
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
Is there a reason for the
clientMetadata
,headers
, andtrailers
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