-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
validating the date format, add test case, since NumberFormatException extends IllegalArgumentException, it is only necessary to write IllegalArgumentException. #2529
Conversation
…NumberFormatException extends IllegalArgumentException, it is only necessary to write IllegalArgumentException.
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great, thanks! Could you add a test, for example in DefaultTypeAdaptersTest
, that fails with the current code and passes with this change? You could use assertThrows
: with the current code the test will fail because no exception will be thrown.
builder.setDateFormat(invalidPattern); | ||
}); | ||
} | ||
@Test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one tiny thing: could you add a blank line before each of these new test methods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I am sorry about that.
Please check again to ensure it meets the requirements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I am just checking this against Google's internal tests to see if they show up anything unexpected. If not, I'll go ahead and merge this.
Should the new tests maybe be moved to Also, could you please change the title of this PR, there is an "Edit" button at the top right of the GitHub UI1. The main change here seems to be about validating the date format, and issue 2472 might not be that closely related that it is worth mentioning it in the final commit message after merge. What do you think about something like this as title (based on what you wrote in the description)?
Footnotes
|
@@ -595,7 +596,12 @@ public GsonBuilder disableHtmlEscaping() { | |||
*/ | |||
@CanIgnoreReturnValue | |||
public GsonBuilder setDateFormat(String pattern) { | |||
// TODO(Joel): Make this fail fast if it is an invalid date format | |||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears null
might actually be a valid pattern
value to clear any custom pattern previously set for the builder. The changes here would not support that anymore.
@eamonnmcmanus, should null
be supported?
Apparently no unit test is covering that yet, might be good to add one (or I can add one in a separate PR if desired).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if pattern is null, here will throw null point exception.
I had change the title. Please check again to ensure it meets the requirements. In addition I'm not sure if I need to move the test cases to |
Yes, you should resolve the conflict. I will merge the PR when it is ready. I don't have a strong opinion on where the new tests should be. We may move them later. On the other hand, I agree with @Marcono1234 that we probably shouldn't change the behaviour for |
offset += 1; | ||
} | ||
// second and milliseconds can be optional | ||
if (date.length() > offset) { |
Check warning
Code scanning / CodeQL
Dereferenced variable may be null Warning
date
this
|
||
if (hasT) { | ||
if (!hasT && (date.length() <= offset)) { |
Check warning
Code scanning / CodeQL
Dereferenced variable may be null Warning
date
this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am trying to solve that
I close the pr, because I make error when I solve conflict. I make a new pr 2538. Sorry for that. |
validating the date format, add test case and since NumberFormatException extends IllegalArgumentException, it is only necessary to write IllegalArgumentException.
Purpose
public GsonBuilder setDateFormat(String pattern)
input pattern is invalid. [Relate issue](Change defaultDate
serialization to ISO 8601 format #2472)public class ISO8601Utils
Checklist
null
@since $next-version$
(
$next-version$
is a special placeholder which is automatically replaced during release)TestCase
)mvn clean verify javadoc:jar
passes without errors