Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

[Issue 54] Removed always-true if and unreachable code in XObject.cs - #55

Closed
andi9310 wants to merge 1 commit into
dotnet:masterfrom
andi9310:issue-54
Closed

andi9310 wants to merge 1 commit into
dotnet:masterfrom
andi9310:issue-54

Conversation

@andi9310

Copy link
Copy Markdown
Contributor

Removed always-true if and unreachable code in XObject.cs

@andi9310 andi9310 changed the title Issue 54 [Issue 54] Removed always-true if and unreachable code in XObject.cs Nov 13, 2014
@andi9310

Copy link
Copy Markdown
Contributor Author

@davkean , thanks for response. As of I understand this code, "IEnumerable Annotations() "method can return IEnumerable with contents, empty IEnumerable, but never null. So "o.Annotations() != null" will always be true. I don't know really if it is supposed to work this way. Maybe It should be "o.Annotations() .Any()" here? As far as i know yielding methods are meant to be used with foreach statements etc. so returning null from them would end with NullReferenceExceptions.

@davkean

davkean commented Nov 13, 2014

Copy link
Copy Markdown
Member

Yep, you are correct that o.Annotations<XObjectChangeAnnotation>() != null will never return null. Looks like they were really supposed to use the non-plural version; o.Annotation<XObjectChangeAnnotation> != null.

However, before we remove or change the check - this particular code was written ~8 years ago, I'd like to get an understanding of the behavior that is broken by that bad check - ie some test cases or code samples that show that fixing this gives a better, but still compatible behavior. For example, are we now firing Changing/Changed events when we're not supposed to?

@davkean

davkean commented Nov 22, 2014

Copy link
Copy Markdown
Member

We appreciate the pull request, however, we've very wary about changing/removing code without tests to prove that an issue exists. Feel free to submit another pull request when you have coverage that covers and proves the bug.

@davkean davkean closed this Nov 22, 2014
@karelz karelz modified the milestone: 1.0.0-rtm Dec 3, 2016
luhenry pushed a commit to luhenry/corefx that referenced this pull request May 24, 2018
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.

5 participants