[IGSTK-Developers] IGSTK - error handling

[Ziv Yaniv]

Hi Luis,

I read the discussion on the wiki and my understanding is that no 
decision was taken, rather errors are handled in various ways, on an 
ad-hoc basis (the implementor makes the final call).

I do not have a preference for a specific error handling approach, only 
that it be consistent across the toolkit, at least the part that is 
exposed to the toolkit user.

Finally, my primary concern is that no error propagation is done (see 
previous mail), no return value, no event generated, no exception 
thrown, no getstatus() method. I believe this is a serious flaw which 
should be addressed as soon as possible, even with a patch. As it stands
the toolkit user will find out that an error occurred when their program 
crashes or stalls.

                  regards
                      Ziv



Luis Ibanez wrote:
> 
> Hi Ziv,
> 
> David summarized our design discussions regarding
> Error Handling in the following Wiki page:
> 
> http://public.kitware.com/IGSTKWIKI/index.php/Error_Handling
> 
> The reason why "GetStatus()" methods are inappropriate in
> general is that they induce a large number of if() statements
> across your application. Code of the sort:
> 
>    service.doSomething();
> 
>    if( service.GetStatus() != 0)
>      {
>      // error
>      }
>     else
>      {
>      }
> 
> 
> This diffusion of logic in "if" statements is a major source
> of bugs and a major limiting factor for raising code coverage.
> 
> 
> The recommended approach for managing errors in IGSTK is
> to use Events in order to report the results of a requested
> operation. The events are received by observer classes that
> are associated to the class that requested the action.
> In order to simplify this mechanism, there are macros that
> allow you to define in a couple of lines of code, a new
> observer and to translate an event into a state machine
> input.
> 
> For example, in your case, the application should be
> implemented as a class with its own state machine. In
> the application class you can use the Macros
> 
>    igstkEventTransductionMacro
>    igstkLoadedEventTransductionMacro
> 
> 
> They will create an observer and the callback for it, that
> will translate events into inputs to the state machine of
> your application.
> 
> In this way you can built in your application the logic
> of what must be done when the Tracker fails to initialize.
> 
> Conceptually you can see it as:
> 
>    the application is in the state:
> 
>           Attempting to Initialize the Tracker
> 
>     and it can receive inputs
> 
>           TrackerInitializationSuccess
> 
> or
>           TrackerInitializationProblem1
>           TrackerInitializationProblem2
>           TrackerInitializationProblem3
> 
> 
> According to each one of those potential inputs, you
> will program an appropriate state transition in the
> state machine of the in the application.
> 
> 
> 
>    Regards,
> 
> 
> -------------------
> Ziv Yaniv wrote:
>> Hi all,
>>
>> Cutting to the chase:
>> How do I handle errors that occur in an IGSTK component at the 
>> application level?
>>
>> Going back to the tracker classes (Aurora):
>> The interface exposed to the outside world does not enable status 
>> checking by the application, no GetStatus() method to see what's up 
>> with the internal state machine, and all methods are declared as void 
>> XXX(), so no return value.
>>
>> Let us say an application wants to initialize a tracker, if this fails 
>> the application user should be alerted. With the current interface I 
>> cannot know if initialization succeeded or failed. The only way to 
>> find out is through a hack (thanks Patrick), using  the 
>> GetNumberOfTools() which should be greater than zero if things are ok, 
>> but as I said this is a hack and not a solution.
>>
>> Does IGSTK have a systematic approach to reporting errors/request 
>> denials to the outside application, and if not what are the plans for 
>> this?
>>
>>              please advise
>>                   Ziv
>>
>> P.S. While I raise this issue for the tracking classes I assume the 
>> situation is similar across IGSTK.
>>
>>
> 
> 
> 


-- 
Ziv Yaniv, PhD., Research Assistant Professor
Imaging Science and Information Systems (ISIS) Center
Department of Radiology
Georgetown University Medical Center
2115 Wisconsin Avenue, Suite 603
Washington, DC, 20007,

Phone: +1-202-687-2902
Fax: +1-202-784-3479
email: zivy at isis.imac.georgetown.edu
web: http://isiswiki.georgetown.edu/zivy/