Skip to content
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

DM-36207: Reset the Fits object status to 0 if we are throwing an error #657

Merged
merged 1 commit into from Sep 14, 2022

Conversation

weatherhead99
Copy link
Contributor

Fix and test case added for https://jira.lsstcorp.org/browse/DM-36207.

@weatherhead99 weatherhead99 self-assigned this Sep 13, 2022
Copy link
Member

@timj timj left a comment

Choose a reason for hiding this comment

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

Thanks for doing this. I have some minor comments. Please also make sure jenkins passes and also include ci_hsc_gen3 in the Jenkins build.

tests/test_fits.py Outdated Show resolved Hide resolved
tests/test_fits.py Outdated Show resolved Hide resolved
include/lsst/afw/fits.h Outdated Show resolved Hide resolved
@weatherhead99
Copy link
Contributor Author

FYI @timj I'm pretty sure for some reason I don't have permission to run it in Jenkins, not sure what the glitch is there...

@erykoff
Copy link
Contributor

erykoff commented Sep 13, 2022

Well, we have to figure out the jenkins thing. You should also change the title of this PR to DM-36207: Reset the Fits object status to 0 if we are throwing an error. See https://developer.lsst.io/work/flow.html#make-a-pull-request

@weatherhead99 weatherhead99 changed the title Reset the Fits object status to 0 if we are throwing an error DM-36207: Reset the Fits object status to 0 if we are throwing an error Sep 13, 2022
@PaulPrice
Copy link
Contributor

On Slack you considered multiple approaches to fixing this. Could I encourage you to capture the logic from those considerations in the commit message so it's not (effectively) lost?

The nature of the cfitsio library is that many calls fail when the status value passed in is not set to a value indicating "success".

Prior to this patch we did not reset that status value after throwing an error, and since the status value is part of the state of the Fits class, any operation after an exception was thrown was liable (though not guaranteed) to fail purely because some previous (invalid) operation failed.

Most notably, when moving to an invalid HDU and back again, moving back would fail for this reason.

Another possible solution to this would be to manually reset status every time we make a cfitsio call, or to alter the LSST_FITS_EXCEPT macro to take a status allowing us to store a temporary and reset the class held value before throwing. The solution chosen, was to construct the exception as per previously, then store it, reset the class status and finally throw the exception.
@weatherhead99
Copy link
Contributor Author

ok I believe all comments have been accounted for and I have squashed this to one commit with a hopefully informative message. Only thing remaining is the Jenkins run I think

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants