-
Notifications
You must be signed in to change notification settings - Fork 535
dcm2niix - Do consider exit 1 to be an error #3594
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
Conversation
Based on information in rordenlab/dcm2niix#733 (comment) > Exit code 0 is for success, exit code 1 is the undefined error. Handling of exit 1 as successful was added in 6ecd4a9 AKA 1.0.2~2^2~13
6e40ed9 to
be5b908
Compare
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@ ## master #3594 +/- ## ======================================= Coverage 63.17% 63.17% ======================================= Files 308 308 Lines 40813 40813 Branches 5654 5654 ======================================= Hits 25784 25784 Misses 14016 14016 Partials 1013 1013
☔ View full report in Codecov by Sentry. |
Should this be made configurable? If I recall, handling a non-error code 1 for HeuDiConv was the motivation, so it may be breaking some workflows to change this. If it's configurable here, HeuDiConv could add a flag.
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.
Because of the amount of non-compliant DICOMs in the wild, I think this added strictness will do more harm than good.
Echoing Chris - perhaps the best thing to do is to add a flag (--strict?) that overrides the correct_return_codes to just (0,). Then users could set/avoid this, depending on their DICOMs' compliance.
well, in a defensive coding style, it feels more like desiring then to make it strict by default but to allow some error codes to be treated as "ok", e.g. may be someone would also want kEXIT_SOME_OK_SOME_BAD to be "ok"?
Where in nipype we should add such an option for "ok_exit_codes" since it does not translate into a command line option for dcm2niix? i.e. I guess it should not be defined in Dcm2niixInputSpec , right?
It could be in the input spec. You would do that if either:
- You want an upstream node to be able to pass this value at workflow run time.
- You want the cache to be invalidated and the node rerun if the value changes.
If neither of these behaviors is desired, I would just set it as an attribute, settable in __init__().
Uh oh!
There was an error while loading. Please reload this page.
Based on information in
rordenlab/dcm2niix#733 (comment)
Handling of exit 1 as successful was added in 6ecd4a9 AKA
1.0.2~2^2~13Closes #3592