-
Notifications
You must be signed in to change notification settings - Fork 530
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
dcm2niix - Do consider exit 1 to be an error #3594
base: master
Are you sure you want to change the base?
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 Where in |
It could be in the input spec. You would do that if either:
If neither of these behaviors is desired, I would just set it as an attribute, settable in |
Based on information in
rordenlab/dcm2niix#733 (comment)
Handling of exit 1 as successful was added in 6ecd4a9 AKA
1.0.2~2^2~13
Closes #3592