-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Provide opt-in for custom converters to handle null #34439
Labels
Milestone
Comments
Dotnet-GitSync-Bot
added
the
untriaged
New issue has not been triaged by the area owner
label
Apr 2, 2020
This was referenced Apr 2, 2020
layomia
added
blocking
Marks issues that we want to fast track in order to unblock other important work
api-ready-for-review
labels
Apr 5, 2020
terrajobst
added
api-needs-work
API needs work before it is approved, it is NOT ready for implementation
and removed
api-ready-for-review
labels
Apr 7, 2020
namespace System.Text.Json.Serialization
{
public partial class JsonConverter<T>
{
public virtual bool HandleNull { get; }
}
} |
Good as proposed, consider nullable annotations on the callback methods. public abstract partial class JsonConverter<T> : System.Text.Json.Serialization.JsonConverter
{
// Also update the nullable annotations for the serialize (parameter)/deserialize (return) callbacks
public virtual bool HandleNull { get { throw null; } }
} |
bartonjs
added
api-approved
API was approved in API review, it can be implemented
and removed
api-needs-work
API needs work before it is approved, it is NOT ready for implementation
blocking
Marks issues that we want to fast track in order to unblock other important work
labels
Apr 30, 2020
In case anyone needs a solution to this problem specifically to be able to serialize an empty |
ghost
locked as resolved and limited conversation to collaborators
Dec 9, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
Motivation
The serializer does not pass
null
to custom converters for reference types on serialization and deserialization. Instead, it handlesnull
by returning a null instance on deserialization (or throwingJsonException
/returning a default value for primitive value types, depending on if there's an internal converter), and writingnull
directly with the writer on serialization. This is primarily for performance to skip an extra call to the converter. In addition, we didn't want callers to have to check for null at the start of everyRead
andWrite
method override.However, the serializer does pass
null
tokens on deserialization to converters for value types. This is to support internal logic for deserializingJsonElement
andNullable<T>
instances, wherenull
is a valid token.null
is also passed to converters for value types because it is not a valid CLR value for these types. This way, the converter can determine what to do with this "invalid" token.This feature provides a way for custom converters to handle
null
, regardless of if they convert value or reference types. It has to be opt-in, otherwise it would be a breaking change.Users may want to handle
null
for various reasons, including validation and setting/writing default values instead ofnull
. Some scenarios:API Proposal
Usage
Notes
HandleNull
default tofalse
for value types because that would be a breaking change.The text was updated successfully, but these errors were encountered: