Exposing two new APIs trySerialize() and tryDeserialize() which do not fail fast on any error occurrence. Instead, they return maximum possible serializable/deserializable object/array and all errors.

[kevi793]

Added two new APIs:
(a) trySerialize<T>(data: T | T[]): {value: any | any[], error: any} { ... }
This method tries to serialize input data and returns value: maximum possible serializable array/object and error: errors found in serialization.
(b) tryDeserialize<T>(json: any, classReference: { new(): T }): {value: any, error: any} { ... }
This method tries to deserialize input json and returns value: maximum possible deserializable array/object and error: errors found in deserialization.

Example usage:-
Snake & Human Class:-

class Snake {
    @JsonProperty("snakeName", String)
    name: string = "";

    @JsonProperty()
    district: number = 0;  

    @JsonProperty("owner", Human)
    owner: Human = undefined;
}

class Human {
    @JsonProperty("givenName", String)
    firstname: string = "";

    @JsonProperty("lastName", String)
    lastname: string = "";
}

Input Json to be deserialized to Snake Type:-

{
	"district": 20,
	  "owner": {
	  	"firstName": "Harry"
	  }
}

{value, error} = jsonconvert.TryDeserialize<Snake>(inputJson, Snake);

Error Object Returned :-

{
	"name": "Property is missing"
  	"owner": {
		"lastname": "Property is missing"
	}
}

Value Object Returned :-

  {
	"name": "",
  	"owner": {
		"firstName": "Harry",
  		"lastname": "Property is missing"
	}
}

[andreas-aeschlimann]

Thank you for this interesting approach.

It's a good idea to add a method to try deserialization and serialization. I didn't have time yet to have a deep look. How do you create an instance of a class partially?

I think the value object returned should be rather

{
	"name": "",
  	"owner": {
		"firstName": "Harry",
  		"lastname": ""
	}
}

(if the property was missing in the JSON, use the default value).

What was your motivation to change the return values of the existing deserialize/serialize methods? I don't think we should change them because this will mean a breaking change for all developers using the library.

[kevi793]

Thanks for immediate feedback on the PR :)

(1) What was your motivation to change the return values of the existing deserialize/serialize methods?

I have changed the return values of only serializeObject()/serializeArray() and deserializeObject()/deserializeArray() methods. The wrapper methods, serialize() & deserialize(), are untouched. Their functionality remains the same. My assumption was that any user would use wrapper methods rather than specific methods for array or object.Now after looking at the documentation examples, I realise that users might be using specific deserialize/serialize methods depending on array or objects.

(2) How do you create an instance of a class partially?

(a) In case of serialization, the *value* will have all valid properties. Missing/Invalid properties will not be present. 
(b) In case of deserialization, corresponding missing/invalid properties in *value* will have default value for that type. 

Looking forward to your code review. I will be happy to contribute if you ask me to address anything or may be changing the implementation to take into account your above mentioned concerns :)

If you feel that we should have this kind of methods (trySerialize() and tryDeserialize()) with all errors, then please let me know.

[kevi793]

Hello Andreas. Updated the PR to retain existing serialize/deserialize methods. Now, there is no breaking experience.