If war is unable to find its own deployment then currently it will return a malformed deployment object and nil for that function. We have checks later that check if the deployment object is nil and handle that case accordingly. Those rely on us returning nil if the deployment is not found.
nil, nil is often an anitpattern in go but it's not in this case because nil is the desired value if self isn't found. self being nil is a concept that's supported within all of the war code. The reason why nil, nil is an antipattern in go is because if you receive a nil error from a function that means you should be able to use the other values (and nil is usually not actually a desired state of other values). This is good because otherwise you'd need multiple nil checks versus just one against error. In this case nil is a valid state of self (it's possible for it not to exist) so this is a fine pattern.
Type of change
Please delete options that are not relevant.
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
How Has This Been Tested?
Tested with unit tests.
Checklist:
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
Description
If war is unable to find its own deployment then currently it will return a malformed deployment object and nil for that function. We have checks later that check if the deployment object is nil and handle that case accordingly. Those rely on us returning nil if the deployment is not found.
nil, nil is often an anitpattern in go but it's not in this case because nil is the desired value if self isn't found. self being nil is a concept that's supported within all of the war code. The reason why nil, nil is an antipattern in go is because if you receive a nil error from a function that means you should be able to use the other values (and nil is usually not actually a desired state of other values). This is good because otherwise you'd need multiple nil checks versus just one against error. In this case nil is a valid state of self (it's possible for it not to exist) so this is a fine pattern.
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Tested with unit tests.
Checklist: