NPE during serialization

[Björn Hachmann <bj...@metrigo.de>]

Repeatedly in the past we ran into the following problem with using Thrift
from Java:

Consider the following simple model:

enum Colour {
  red,
  blue
}

struct Product {
  string sku;
  map<Colour, i32> inventory;
}

In our scenario Service A uses this version of the model. Service B uses a
newer version in which a new enum value "green" has been introduced.

Under the following circumstances:
1) B serializes a product in which an inventory entry is contained for
green.
2) A deserializes this product. As it does not know of green yet, the
problematic map key is deserialized as null.
3) A serializes the product again and runs into a NullPointerException.

My questions are:
1) Could this be a bug or should we somehow implement counter measures
against such cases? I think it feels a little weird to run
into this issue when using Thrift as there are several other similar
scenarious in which such a version mismatch is handled more gracefully.
2) Are there any best practices to deal with this case?

Thank you for your opinion!

Kind regards
Bjoern Hachmann

Re: NPE during serialization

[Jens Geyer <je...@hotmail.com>]

IMHO an NPE should not happen. That sounds strange to me. I'd recommend to 
file a JIRA ticket.



-----Ursprüngliche Nachricht----- 
From: Björn Hachmann
Sent: Tuesday, September 22, 2015 4:01 PM
To: user@thrift.apache.org
Subject: NPE during serialization

Repeatedly in the past we ran into the following problem with using Thrift
from Java:

Consider the following simple model:

enum Colour {
  red,
  blue
}

struct Product {
  string sku;
  map<Colour, i32> inventory;
}

In our scenario Service A uses this version of the model. Service B uses a
newer version in which a new enum value "green" has been introduced.

Under the following circumstances:
1) B serializes a product in which an inventory entry is contained for
green.
2) A deserializes this product. As it does not know of green yet, the
problematic map key is deserialized as null.
3) A serializes the product again and runs into a NullPointerException.

My questions are:
1) Could this be a bug or should we somehow implement counter measures
against such cases? I think it feels a little weird to run
into this issue when using Thrift as there are several other similar
scenarious in which such a version mismatch is handled more gracefully.
2) Are there any best practices to deal with this case?

Thank you for your opinion!

Kind regards
Bjoern Hachmann