EnumSpec: Add support for MustUnmarshalText function

[hlin117]

#309 implemented the encoding.Unmarshaler so []byte types can be converted into enum values. For example, this function can now be generated.

// UnmarshalText tries to decode ImpressionType from a byte slice
// containing its name.
//
//   var v ImpressionType
//   err := v.UnmarshalText([]byte("OPENED"))
func (v *ImpressionType) UnmarshalText(value []byte) error {
	switch string(value) {
	case "OPENED":
		*v = ImpressionTypeOpened
		return nil
	case "COMPLETED":
		*v = ImpressionTypeCompleted
		return nil
	default:
		return fmt.Errorf("unknown enum value %q for %q", value, "ImpressionType")
	}
}

It would be nice if an additional mapper, MustUnmarshalText, were implemented, like so:

func (v *ImpressionType) MustUnmarshalText(value []byte) {
    if err := v.UnmarshalText(value); err != nil {
        panic(err)
    }
}

Related: #134

[abhinav]

The UnmarshalText method was implemented to satisfy the encoding.TextUnmarshaler interface.

I would prefer not to generate functions that panic-by-default, especially in
this case where panicing in the caller is pretty easy.

[hlin117]

I would prefer not to generate functions that panic-by-default, especially in
this case where panicing in the caller is pretty easy.

That's fair. My use case is we have a datastore which stores the enums as a string representation. So we know that these strings will translate perfectly into an enum value.

[abhinav]

You don't necessarily have that guarantee because additions to the enum won't
propagate to all instances of your service at the same time.

Suppose you add a new enum entry and deploy the change. While the deployment
is in flight, one of the upgraded instances of your service processes a
request and puts the value in the database. Another instance that has not yet
upgraded ends up reading that entry from the database and doesn't know what it
means.

You always want to have a catch-all case. It can return an error upstream
rather than causing your service to crash with a panic.

[kriskowal]

@hlin117 have you considered the case of retrieving a string from the database, with a client that was generated with an older version of the IDL and does not recognize the string? If the database stores the underlying number (perhaps alongside the string for human readers), old clients would be able to deserialize the value regardless of whether it is known to the version of the client.

[hlin117]

You two are right; serialization does get tricky if there are IDL inconsistencies between two instances of the service.

Given these cases, I'm willing to close this issue as is. Thanks for your feedback!