Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Number handling with converters #57525

Merged
merged 5 commits into from
Aug 17, 2021

Conversation

steveharter
Copy link
Member

@steveharter steveharter commented Aug 16, 2021

Replacement PR for #42239. It has the same semantics as that PR; just merged to latest code and added a test\sample.

Fixes #51685

@ghost
Copy link

ghost commented Aug 16, 2021

Tagging subscribers to this area: @eiriktsarpalis, @layomia
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author: steveharter
Assignees: -
Labels:

area-System.Text.Json

Milestone: -

@steveharter steveharter self-assigned this Aug 16, 2021
@steveharter steveharter added this to the 6.0.0 milestone Aug 16, 2021
// Ensure custom converter is honored.
var obj = JsonSerializer.Deserialize<ClassWith_NumberHandlingOn_Property_WithCustomConverter>(json);
Assert.Equal(25, obj.Prop);
Assert.Throws<NotImplementedException>(() => JsonSerializer.Serialize(obj));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was initially confused by this assertion, but then I realized it's an exception thrown by the custom converter. Do we need to test for this here? Or if we do, shouldn't we be testing an implemented converter?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The read side is implemented to return 25, so I believe it is implied the write side will of course get called and thus is kept simple by just throwing instead of writing 25.

There are tests later that has both read- and write- sides

Assert.Contains(typeof(ConverterForMyType).ToString(), exAsStr);
Assert.Contains(typeof(ClassWith_NumberHandlingOn_Type_WithCustomConverter).ToString(), exAsStr);
// Assert regular Read/Write methods on custom converter are called.
Assert.Throws<NotImplementedException>(() => JsonSerializer.Deserialize<ClassWith_NumberHandlingOn_Type_WithCustomConverter>(json));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to my comment above, throwing NotImplementedException to test whether a custom converter is being exercised is hard to parse. I think we need to test for the happy path (if anything because we might have an undetected regression because another part of the testing infrastructure throws the same exception type, or because there might be another bug hiding downstream of the thrown exception).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added additional comments to clarify this, and also returned a literal in the exception text to verify it was coming from the custom converter. We can discuss further with @layomia in a follow-up.

Copy link
Member

@eiriktsarpalis eiriktsarpalis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than a few issues with testing, LGTM. Thanks!

@steveharter steveharter merged commit d6ea158 into dotnet:main Aug 17, 2021
@steveharter steveharter deleted the NumberHandlingWithConverters branch August 17, 2021 18:35
@ghost ghost locked as resolved and limited conversation to collaborators Sep 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Custom Json Serializer Options are omitted if a NumberHandling flag is not set
3 participants