-
Notifications
You must be signed in to change notification settings - Fork 11
When deserialization fails, default instead of null value should be provided #1292
Comments
… the data from default instance are set #1292
Do we need onDeserialize() method then? |
Actually imho yes .. or at least with design of some configurations. Imagine the situation .. And still you may want to have several transient fields in your configuration and somehow compute them before/after serialization from serialized data. |
In case of deserializing configuration from XStream, it works in a way that On Mon, Mar 10, 2014 at 8:35 AM, Petr Škoda [email protected]:
|
XStream do deserialization .. and set whatever he can .. we watch this process and take a note of all set fields. Then we use reflection to get list of all fields in configuration and if there are fields that has not been set, then we create default configuration (empty ctor) and use getters/setters to copy required values. |
Ok. So the basic advice is - if you need any initialization (apart from the On Mon, Mar 10, 2014 at 8:53 AM, Petr Škoda [email protected]:
|
Suppose that user:
Better behaviour: When there is an error when deserializing certain attribute, instead of using null and calling onDeserialize(), it would be better to set the default value and then call on Deserialize().
How to do it: When there is an error deserializing certain attribute, you may create new instance and try to get, via reflection, the default value for that attribute.
Motivation: onDeserialize() can serve in the same way, but it duplicated the effort of DPU developer, he has to initialize the attribute on two places which may introduce errors.
The text was updated successfully, but these errors were encountered: