-
Notifications
You must be signed in to change notification settings - Fork 96
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
Add exception handling instead of return value checks on DCMTK GetElement* calls #46
Comments
This isn't the case -- DCMTKFileReader will (by default) throw an exception, but DCMTK::DataSet::GetElement does not -- it returns an error code. |
Sorry, I confused the two. Modules/IO/DCMTK/src/itkDCMTKFileReader.cxx:939 is where the exception is thrown, yes it's DCMTKFileReader. Still, the issue remains that it has to be caught. |
Kent, do you acknowledge this is a bug? |
The situation is this: DWIConvert is meant to be primarily, even If you want to read non-DWI gradient series there are other tools Do you have a patch for the problem as you percieve it?Kent Williams norman-k-williams@uiowa.edu On 6/27/13 10:52 AM, "Andrey Fedorov" notifications@github.com wrote:
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. |
I am confused.
Because of the above, I don't see how this is not a bug. And I do not see why it should be expected that my DWI series should not be converted. Sure, I can contribute a patch that will fix the specific issue I have - wrap that particular call in try/catch. However, I don't think this is the right way to do it. Either all similar calls should be wrapped in try/catch, or the GetElement*() calls in DCMTK ITK reader should be fixed to return error, instead of throwing exception. Kent, you are the main contributor to both DWIConvert and DCMTK reader, so I thought you are in the best position to make the choice between the two above. What do you think? |
Andrey, We are also confused. All the previous e-mails you sent seemed to indicate that this was a time series, not a DWI series (hence my comment to try –fMRI flag). Can you provide an anonymized version of this file format so that we can actually work on data rathter than guessing what is wrong. For every data set we had access to (a large body of scanner/dicom types), we confirmed that DWIConvert produced equivalent results for both Dicom2Nrrd and DWIConvert. If we have inadvertently introduced a regression on a data set that is not available to us, we are sorry, but we won't be able to effectively resolve this issue when we are blind to what the actual problem is, and for the over 3000 DWI scan sessions from more than 30 sites we have not run into the problem that you express. Please provide us something that we can actually evaluate, a patch is greatly appreciated because it is the most clear way to communicate what you expect to happen, and it has the side effect of allowing you to test your hypothesis that this will fix your problem without breaking the current test suite. If that is the case, then we will be happy to propagate your proven result throughout the rest of the tool. Hans From: Andrey Fedorov <notifications@github.commailto:notifications@github.com> I am confused.
Because of the above, I don't see how this is not a bug. And I do not see why it should be expected that my DWI series should not be converted. Sure, I can contribute a patch that will fix the specific issue I have - wrap that particular call in try/catch. However, I don't think this is the right way to do it. Either all similar calls should be wrapped in try/catch, or the GetElement*() calls in DCMTK ITK reader should be fixed to return error, instead of throwing exception. Kent, you are the main contributor to both DWIConvert and DCMTK reader, so I thought you are in the best position to make the choice between the two above. What do you think? — Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. |
Hans, I sent the dataset to Kent by email first time I reported the issue. I will resend that email (I don't want to make the data public). Here's the description of the problem - what is confusing here: the way it is now, this code https://github.com/BRAINSia/BRAINSTools/blob/master/DWIConvert/GEDWIConverter.h#L96-L99 will never be executed, because GetElementOB() either returns EXIT_SUCCESS, or throws an exception (see https://github.com/Kitware/ITK/blob/master/Modules/IO/DCMTK/src/itkDCMTKFileReader.cxx#L941-L943). There are a lot of other similar places in DWIConvert. There are three different ways to fix the problem:
IMO, 3 is the optimal approach, but you are the architects of both, so please tell me what you think is right! |
Kent will be on vacation, if you provide a patch that can be tested, someone else can test. I'll ask Kent to take a close look at it when he returns from vacation. Hans From: Andrey Fedorov <notifications@github.commailto:notifications@github.com> Hans, I sent the dataset to Kent by email first time I reported the issue. I will resend that email (I don't want to make the data public). Here's the description of the problem - what is confusing here: the way it is now, this code https://github.com/BRAINSia/BRAINSTools/blob/master/DWIConvert/GEDWIConverter.h#L96-L99 will never be executed, because GetElementOB() either returns EXIT_SUCCESS, or throws an exception (see https://github.com/Kitware/ITK/blob/master/Modules/IO/DCMTK/src/itkDCMTKFileReader.cxx#L941-L943). There are a lot of other similar places in DWIConvert. There are three different ways to fix the problem:
IMO, 3 is the optimal approach, but you are the architects of both, so please tell me what you think is right! — Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. |
Andriy (Andrey? You're listed both ways in E-mail headers). I am back, and looking at your problem. I've downloaded the test dataset. The problem with that dataset is that it appears to be completely lacking [0019,10bb],[0019,10bc],[0019,10bd] These are missing from the file, and using DCMDump (which builds as part The patch you submitted simply suppresses throwing an exception when the Furthermore there are only 40 slices present in that dataset, which would So I'm a little confused about what you think is proper operation of As I've said before, there are other tools for converting DICOM data sets |
It turns out, DCMTK GetElement* do not return non-success value on failure. Instead they throw exceptions: eg see Modules/IO/DCMTK/src/itkDCMTKFileReader.cxx:939.
As a result, failure to find a certain element in the input DICOM series leads to failure of the DWIConvert tool.
This can be fixed by adding try {} catch (...) {} around the calls. I did this for my use case, and it fixed the problem.
The text was updated successfully, but these errors were encountered: