Skip to content

Address JsonElement doc and test feedback#43832

Merged
steveharter merged 2 commits intodotnet:masterfrom
steveharter:JsonElementFollowup
Oct 30, 2020
Merged

Address JsonElement doc and test feedback#43832
steveharter merged 2 commits intodotnet:masterfrom
steveharter:JsonElementFollowup

Conversation

@steveharter
Copy link
Contributor

Address feedback from #43601

@steveharter steveharter added documentation Documentation bug or enhancement, does not impact product or test code area-System.Text.Json test-enhancement Improvements of test source code labels Oct 26, 2020
@steveharter steveharter added this to the 6.0.0 milestone Oct 26, 2020
@steveharter steveharter requested a review from jozkee as a code owner October 26, 2020 17:33
@steveharter steveharter self-assigned this Oct 26, 2020
ex = e;
}

Assert.Equal(0, reader.BytesConsumed);
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing asserts on ex.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep. Thanks

ex = null;
}
catch (JsonException) { }
catch (Exception e)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be:

Suggested change
catch (Exception e)
catch (JsonException e)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It could be, but I followed the pattern in JsonDocumentTests, which I believe wants to fail with a nice Assert instead of a unhandled exception.

/// </remarks>
/// <exception cref="ArgumentException">
/// <paramref name="reader"/> is using unsupported options.
/// <paramref name="reader"/> contains unsupported options.
Copy link
Contributor

@ahsonkhan ahsonkhan Oct 26, 2020

Choose a reason for hiding this comment

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

Is this where we landed on the doc sentence?

From reading #43601 (comment), I thought we'd keep "is using unsupported options" across the board instead (and update dotnet-api-docs accordingly).

Suggested change
/// <paramref name="reader"/> contains unsupported options.
/// <paramref name="reader"/> is using unsupported options.

Copy link
Contributor

Choose a reason for hiding this comment

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

Choose a reason for hiding this comment

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

"is using" makes more sense to me.

Copy link
Contributor Author

@steveharter steveharter Oct 29, 2020

Choose a reason for hiding this comment

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

Since the docs have been reviewed after the original comments in code were ported, I assumed docs win.

However, it looks a little messy:

  • The original code used "contains" and is still using that
  • When originally ported to dotnet-api-docs it used "contains"
  • Another pass was made to dotnet-api-doc changing from "is using" to "contains" although history doesn't show the "is using" change...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I reverted the "contains" changes.

However, there are also similar "contains unsupported options" elsewhere for JsonDocumentOptions; I don't have a preference here.

Copy link
Contributor

@ahsonkhan ahsonkhan Oct 30, 2020

Choose a reason for hiding this comment

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

Is there an issue tracking the docs update, in dotnet-api-docs, to make the wording consistent (is using unsupported options)?

It's nice to have the XML comments in source match what's in the official docs/IntelliSense, but not absolutely necessary. The priority is getting the donet-api-docs to be accurate and consistent because that is the source of truth, which customers/end users see.

@steveharter steveharter merged commit f8e1365 into dotnet:master Oct 30, 2020
@steveharter steveharter deleted the JsonElementFollowup branch October 30, 2020 14:37
@ghost ghost locked as resolved and limited conversation to collaborators Dec 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-System.Text.Json documentation Documentation bug or enhancement, does not impact product or test code test-enhancement Improvements of test source code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants