[IGSTK-Developers] Get method possibilities

[David Gobbi]

Hi Luis,

My preference in this case is #1.

I actually think that exceptions are the
better solution, but I don't want to see
any exceptions added just before
a release.

 - David

Luis Ibanez wrote:

>
> Hi David,
>
> Thanks for posting the alternative options
> for implementing the unsafe Get() methods.
>
> -- 
>
> What would be your preference between the
> options:
>
>
>     1) Adding FileSuccessfullyRead()
>        removing the booleans and adding
>        the [const std::strings &] on return.
>
> or
>
>
>     3) Throwing Exceptions when the
>        values are not available.
>
>
>
> [ Option (2) is the current one,
>   so I would guess it is not int the list.
>   The purpose of having the boolean to be
>   returned by the same Get method was to
>   ensure that the precondition and the action
>   were performed as an atomic operation, but
>   I agree with you in that we should not use
>   any code that resembles FORTRAN. ]
>
>
> -- 
>
> Given that the Get() methods are now tagged and
> recorded in the Logger, we could easily go with
> any of the three proposed alternatives, since
> none of those is quite fit for a State Machine
> architecture anyways.
>
>
> We just need to pick up the one that will reduce
> the developer's effort to a bare minimum, make
> them feel more comfortable, and provide them with
> the maximum of flexibility.
>
>
> Please let us know what would be your preference
> so we can make these changes today before moving
> the code to the main IGSTK library.
>
>
>   Thanks
>
>
>      Luis
>
>
> -------------------
> David Gobbi wrote:
>
>> Hi All,
>>
>> The ImageReader Get methods that were just added to CVS are a
>> bit clunkier than I would like,  due to the boolean return value.  In
>> VTK and ITK, the methods would return the string (or a const
>> reference to the string) and forgo the boolean return value.
>>
>> Typical VTK/ITK code looks like this:
>>
>> if (reader->FileSuccessfullyRead())
>> {
>> std::string   patientName = reader->GetPatientName();
>> std::string   patientID = reader->GetPatientID();
>> std::string   modality = reader->GetModality();
>>
>> .. plus additional code to process the information
>> }
>> ... at this point in the code, the patientName, patientID, and modality
>>   variables are no longer in scope, so there is no danger of them being
>>   used if the file hasn't been read yet.
>>
>> With the methods that were just added (with the boolean return value),
>> the code will look like this:
>>
>> std::string patientName;
>> if (reader->GetPatientName(patientName))
>>  {
>>   ... use the patient name
>>  }
>> std::string patientID;
>> if (reader->GetPatientID(patientID))
>>  {
>>  ... use the patient ID
>>  }
>> ... and so on for modality
>>
>> ... at this point in the code, the "patientName", "patientID", and 
>> "modality"
>>   variables are all still in scope, even if the Get() methods 
>> failed.  This sort
>>   of a programming pattern reminds me of FORTRAN.
>>
>> Just my two cents.
>>
>> - David
>>
>> P.S. I can't resist adding an example that uses exceptions:
>>
>> try
>>   {
>>   std::string   patientName = reader->RequestPatientName();
>>   std::string   patientID = reader->RequestPatientID();
>>   std::string   modality = reader->RequestModality();
>>   .. plus additional code to use the information, not executed if an 
>> exception occurs
>>   }
>>  catch (InvalidRequest)
>>   {
>>   ... send debug info to logger
>>   }
>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>
>>
>
>