fix panic, when service Handler returns (nil, nil)

[holdno]

Fix panic, when service Handler returns (nil, nil)

Why wasn't this done before? Is it because it introduced reflection?

[dfawley]

Why wasn't this done before? Is it because it introduced reflection?

Probably. I don't think it's a good idea to bring in reflection. Isn't this a programming error if it happens, anyway?

[holdno]

Why wasn't this done before? Is it because it introduced reflection?

Probably. I don't think it's a good idea to bring in reflection. Isn't this a programming error if it happens, anyway?

or fix it in go-gen handler.

handler := func(ctx context.Context, req interface{}) (interface{}, error) {
    reply, err := srv.(MetricsServiceServer).GetGauge(ctx,  req.(*GaugeRequest))
    if reply == nil {
        return nil, err
    }
    return reply, err
}

I believe that regardless of whether it's the developer's fault that leads to two nil return values, the framework should not continue to pass down a 'nil' that cannot be confirmed as nil. This leads to multiple implementations having to defend against this issue downstream, and developers being unable to anticipate the error messages they might receive.

Alternatively, this could be a bug in the implementation of protobuf serialization.

proto.Marshal(vv)
// Marshal impl:
func Marshal(m Message) ([]byte, error) {
	if m == nil { // not matched
		return nil, nil
	}

	out, err := MarshalOptions{}.marshal(nil, m.ProtoReflect())
	if len(out.Buf) == 0 && err == nil {
		out.Buf = emptyBytesForMessage(m)
	}
	return out.Buf, err
}