[IGSTK-Developers] IGSTK - error handling

[Luis Ibanez]

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.
> 
>