Fix possible nil pointer dereference in APIError.NotFound() method #271
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If someone were to receive a PagerDuty response that did not contain the error JSON object, they would hit a nil pointer dereference if they attempted to call the .NotFound() method if the status code is not 404. This fixes it by doing a nil check before attempting to read the value to do the comparison.
|
I'm also working on an alternative API, which will avoid consumers having the same problem in their code. Since we haven't released v1.4.0 yet we should consider it... |
theckman
added a commit
that referenced
this pull request
Feb 12, 2021
I discovered that my initial implementation of the APIError type's NotFound() method had the potential for triggering a nil pointer dereference panic, which wouldn't be a great experience for someone dealing with PagerDuty code. I provided a fix in #271, but in doing so I remembered this pattern from the `database/sql` package and decided that, while not as nice to use, it was a much safer API to reduce the chances of the consumer accidentally triggering a panic in their program. Since we've yet to release v1.4.0 (i.e., the new APIError type still hasn't been released) we can still change this without breaking API compatibility guarantees.
theckman
added a commit
that referenced
this pull request
Feb 12, 2021
I discovered that my initial implementation of the APIError type's NotFound() method had the potential for triggering a nil pointer dereference panic, which wouldn't be a great experience for someone dealing with PagerDuty code. I provided a fix in #271, but in doing so I remembered this pattern from the `database/sql` package and decided that, while not as nice to use, it was a much safer API to reduce the chances of the consumer accidentally triggering a panic in their program. Since we've yet to release v1.4.0 (i.e., the new APIError type still hasn't been released) we can still change this without breaking API compatibility guarantees.
|
I'm going to close this pull request in-favor of #272. |
theckman
added a commit
that referenced
this pull request
Feb 12, 2021
I discovered that my initial implementation of the APIError type's NotFound() method had the potential for triggering a nil pointer dereference panic, which wouldn't be a great experience for someone dealing with PagerDuty code. I provided a fix in #271, but in doing so I remembered this pattern from the `database/sql` package and decided that, while not as nice to use, it was a much safer API to reduce the chances of the consumer accidentally triggering a panic in their program. Since we've yet to release v1.4.0 (i.e., the new APIError type still hasn't been released) we can still change this without breaking API compatibility guarantees.
theckman
added a commit
that referenced
this pull request
Feb 12, 2021
I discovered that my initial implementation of the APIError type's NotFound() method had the potential for triggering a nil pointer dereference panic, which wouldn't be a great experience for someone dealing with PagerDuty code. I provided a fix in #271, but in doing so I remembered this pattern from the `database/sql` package and decided that, while not as nice to use, it was a much safer API to reduce the chances of the consumer accidentally triggering a panic in their program. Since we've yet to release v1.4.0 (i.e., the new APIError type still hasn't been released) we can still change this without breaking API compatibility guarantees.
theckman
added a commit
that referenced
this pull request
Feb 12, 2021
I discovered that my initial implementation of the APIError type's NotFound() method had the potential for triggering a nil pointer dereference panic, which wouldn't be a great experience for someone dealing with PagerDuty code. I provided a fix in #271, but in doing so I remembered this pattern from the `database/sql` package and decided that, while not as nice to use, it was a much safer API to reduce the chances of the consumer accidentally triggering a panic in their program. Since we've yet to release v1.4.0 (i.e., the new APIError type still hasn't been released) we can still change this without breaking API compatibility guarantees.
theckman
added a commit
that referenced
this pull request
Feb 12, 2021
I discovered that my initial implementation of the APIError type's NotFound() method had the potential for triggering a nil pointer dereference panic, which wouldn't be a great experience for someone dealing with PagerDuty code. I provided a fix in #271, but in doing so I remembered this pattern from the `database/sql` package and decided that, while not as nice to use, it was a much safer API to reduce the chances of the consumer accidentally triggering a panic in their program. Since we've yet to release v1.4.0 (i.e., the new APIError type still hasn't been released) we can still change this without breaking API compatibility guarantees.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If someone were to receive a PagerDuty response that did not contain the error
JSON object, they would hit a nil pointer dereference if they attempted to call
the .NotFound() method if the status code is not 404.
This fixes it by doing a nil check before attempting to read the value to do the
comparison.