You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Przemysław Pawelec <pr...@codilime.com> on 2015/08/13 13:21:19 UTC
Dealing with silent fails of findByValue of Thrift enums
Dear all,
Currently Java code of 'findByValue' method of Thrift enums returns a null
when a received number doesn't correspond to an existing value. This
coincides with a null set for an optional enum.
Thus, outside of a Thrift code we can't check whether an invalid value is
passed.
Can we somehow make Thrift enums throw an exception on 'default' case?
Best regards,
Przemysław Pawelec
Intern
---------------------------------
CodiLime Sp. z o.o. - Ltd. company with its registered office in Poland,
01-167 Warsaw, ul. Zawiszy 14/97. Registered by The District Court for the
Capital City of Warsaw, XII Commercial Department of the National Court
Register. Entered into National Court Register under No. KRS 0000388871.
Tax identification number (NIP) 5272657478. Statistical number (REGON)
142974628.
-----------------------------------------
The information in this email is confidential and may be legally
privileged, it may contain information that is confidential in CodiLime Sp.
z o.o. It is intended solely for the addressee. Any access to this email by
third parties is unauthorized. If you are not the intended recipient of
this message, any disclosure, copying, distribution or any action
undertaken or neglected in reliance thereon is prohibited and may result in
your liability for damages.
Re: Dealing with silent fails of findByValue of Thrift enums
Posted by Jens Geyer <je...@hotmail.com>.
Some additional comments:
> Currently Java code of 'findByValue' method of Thrift enums returns a null
> when a received number doesn't correspond to an existing value. This
> coincides with a null set for an optional enum.
In both cases the enum value is not present.
> Thus, outside of a Thrift code we can't check whether an invalid value is
> passed.
If the distinction between "not present because this value has not been set"
and "not present because no value has been set at all" is really that
relevant, consider wrapping the enum into a struct. Then ask the public
boolean isSetMyEnum() function which will tell you whether or not the struct
member has been set.
> The information in this email is confidential and may be legally
> privileged,
You shouldn't send this to a public mailing list then ... ;-)
-----Ursprüngliche Nachricht-----
From: Jens Geyer
Sent: Thursday, August 13, 2015 10:54 PM
To: user@thrift.apache.org
Subject: Re: Dealing with silent fails of findByValue of Thrift enums
Hi,
that's an interesting question.
>From my point of view you should do that in your handler code. Why?
Thrift IDL is soft-versionable, which implies that an enum may change over
time (i.e. new enum values may be added). So testing against a fixed,
immutable set of enum values is not an absolute: What you are really doing
is "testing against a snapshot of current knowledge" - the knowledge that is
burned into the code at the time the code is generated from a given version
of the IDL. If you take a newer version of the same IDL, generate and
compile again, you get a newer "snapshot of current knowledge" burned into
your binaries.
A not so unusal use case is putting an old client (IDL v1) against a new
server (IDL v2). The server may now send back an enum value unknown to the
client. This is a perfectly legal case. The question whether an unknown enum
value in the context of the problem domain is a fatal problem that is
properly handled only by an immediate termination of the client program, or
only some value that can be safely ignored, or something between these two
extremes depends solely on two things:
a) the semantics of that enum and it's values
b) the problem domain
But here's the problem: Thrift only transports data, it does not know so
much about the semantics of your enum values vis-à-vis your problem domain.
And frankly, it shouldn't.
Hence, it sounds not like a good idea to throw on an unknown enum value,
because "unknown" may mean exactly this - "unknown to me", but not
necessarily "completely illegal value". If the problem domain layers have to
care about these values, then this is the right place to validate and take
whatever action is appropriate.
Have fun,
jensG
-----Ursprüngliche Nachricht-----
From: Przemysław Pawelec
Sent: Thursday, August 13, 2015 1:21 PM
To: user@thrift.apache.org
Subject: Dealing with silent fails of findByValue of Thrift enums
Dear all,
Currently Java code of 'findByValue' method of Thrift enums returns a null
when a received number doesn't correspond to an existing value. This
coincides with a null set for an optional enum.
Thus, outside of a Thrift code we can't check whether an invalid value is
passed.
Can we somehow make Thrift enums throw an exception on 'default' case?
Best regards,
Przemysław Pawelec
Intern
---------------------------------
CodiLime Sp. z o.o. - Ltd. company with its registered office in Poland,
01-167 Warsaw, ul. Zawiszy 14/97. Registered by The District Court for the
Capital City of Warsaw, XII Commercial Department of the National Court
Register. Entered into National Court Register under No. KRS 0000388871.
Tax identification number (NIP) 5272657478. Statistical number (REGON)
142974628.
-----------------------------------------
The information in this email is confidential and may be legally
privileged, it may contain information that is confidential in CodiLime Sp.
z o.o. It is intended solely for the addressee. Any access to this email by
third parties is unauthorized. If you are not the intended recipient of
this message, any disclosure, copying, distribution or any action
undertaken or neglected in reliance thereon is prohibited and may result in
your liability for damages.
Re: Dealing with silent fails of findByValue of Thrift enums
Posted by Jens Geyer <je...@hotmail.com>.
Hi,
that's an interesting question.
>From my point of view you should do that in your handler code. Why?
Thrift IDL is soft-versionable, which implies that an enum may change over
time (i.e. new enum values may be added). So testing against a fixed,
immutable set of enum values is not an absolute: What you are really doing
is "testing against a snapshot of current knowledge" - the knowledge that is
burned into the code at the time the code is generated from a given version
of the IDL. If you take a newer version of the same IDL, generate and
compile again, you get a newer "snapshot of current knowledge" burned into
your binaries.
A not so unusal use case is putting an old client (IDL v1) against a new
server (IDL v2). The server may now send back an enum value unknown to the
client. This is a perfectly legal case. The question whether an unknown enum
value in the context of the problem domain is a fatal problem that is
properly handled only by an immediate termination of the client program, or
only some value that can be safely ignored, or something between these two
extremes depends solely on two things:
a) the semantics of that enum and it's values
b) the problem domain
But here's the problem: Thrift only transports data, it does not know so
much about the semantics of your enum values vis-à-vis your problem domain.
And frankly, it shouldn't.
Hence, it sounds not like a good idea to throw on an unknown enum value,
because "unknown" may mean exactly this - "unknown to me", but not
necessarily "completely illegal value". If the problem domain layers have to
care about these values, then this is the right place to validate and take
whatever action is appropriate.
Have fun,
jensG
-----Ursprüngliche Nachricht-----
From: Przemysław Pawelec
Sent: Thursday, August 13, 2015 1:21 PM
To: user@thrift.apache.org
Subject: Dealing with silent fails of findByValue of Thrift enums
Dear all,
Currently Java code of 'findByValue' method of Thrift enums returns a null
when a received number doesn't correspond to an existing value. This
coincides with a null set for an optional enum.
Thus, outside of a Thrift code we can't check whether an invalid value is
passed.
Can we somehow make Thrift enums throw an exception on 'default' case?
Best regards,
Przemysław Pawelec
Intern
---------------------------------
CodiLime Sp. z o.o. - Ltd. company with its registered office in Poland,
01-167 Warsaw, ul. Zawiszy 14/97. Registered by The District Court for the
Capital City of Warsaw, XII Commercial Department of the National Court
Register. Entered into National Court Register under No. KRS 0000388871.
Tax identification number (NIP) 5272657478. Statistical number (REGON)
142974628.
-----------------------------------------
The information in this email is confidential and may be legally
privileged, it may contain information that is confidential in CodiLime Sp.
z o.o. It is intended solely for the addressee. Any access to this email by
third parties is unauthorized. If you are not the intended recipient of
this message, any disclosure, copying, distribution or any action
undertaken or neglected in reliance thereon is prohibited and may result in
your liability for damages.