[IGSTK-Developers] IGSTK - error handling

[David Gobbi]

Hi Ziv,

In the tracker, the slots exist where the error events should be 
generated, i.e. the state machine calls specific functions when errors 
occur, but right now those methods only log the error but don't generate 
an event.  Yes, this needs to be fixed, and I'm the one who needs to fix 
it.  The example applications in IGSTK don't catch any error events, 
either... hardly ideal examples!

 - David



Ziv Yaniv wrote:
> 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.
>>>
>>>
>>
>>
>>
>
>