[IGSTK-Developers] (no subject)

[Patrick Cheng]

Hi Torleif,

Thanks for this thorough email regarding error and event handling. It 
provides an excellent summary from the user's perspective. I will give 
you some quick answers here according to our past tcon discussion. Also, 
this email makes a very good requirement documentation, I will put it on 
the requirement page under event management.

1. The new hierarchy will enables this.

2. Haven't considered the error message load yet

3. If you create an observer to observe igstkErrorEvent from one 
particular igstk object, it will catch "each error event that may 
arise". To know what exact error it is, you can do a type checking in 
the observer's callback function. Something like:
   SomeErrorEvent().CheckEvent( &event );
This will return true, if the event evoke the callback is type of 
"SomeErrorEvent".

4. Documenting event is something must be improved

5&6. Event is not the correct way for system error handling. This is a 
known issue for our current design. For the moment, we need to develop a 
guideline and demo applications to show how and the right way to handle 
igstk events.

Thank you again for your suggestions, I hope you enjoy your leave.

Patrick


Sandnes Torleif wrote:
> Hi Everybody.
> 
> I am currently on paternity leave and will be back at work in early August, but will try to 
> keep myself updated on the development of IGSTK and maybe post some comments from time to time. 
> 
> I see from the last minutes that there will be a refactoring of the event hierarchy.
> It looks like the new hierarchy will be a great improvement on the old one. It makes sense to
> separate error events from normal events, and I agree that the multiple-inheritance approach
> maybe would be a bit of an overkill. 
> 
> Error handling in IGSTK applications is an issue I have found it somewhat hard to get a grip on 
> (as an app. developer). I have some comments and questions based on my experiences:
> 
> 1. For an app.developer that is working on a specific component I understand that he can just create
>    a subscriber for igstkErrorEvent and add that to the component. He will then get all ErrorEvents 
>    that component emits. Also, it is possible to create a subscriber for igstkErrorEvents and add this 
>    to all components So with this approach we can have one subscriber that registers with all 
>    components for error events and have this observe all errorevents if that is desireable.
> 2. What kind of load will error events have? It would be nice with a descriptive error message. 
>    Not necessarily meant for the user of the software, but something that makes sense for the developer. 
>    And maybe it would be possible to attach information about where the error originated?
> 3. Is it feasible to have one class for each error event that may arise? Would it be better to 
>    let one class represent a set of similar errors and add an enumerated value describing the exact error?
> 4. In any case, it should be clearly documented (doxygen) which events a component may emit in response to
>    requests.
> 5. What happens when an error occurs in a component and no observer is observing this kind of error?
>    Would it be justifiable to throw an exception in these cases? If I Remember Correctly such errors will
>    be silently ignored if not observed. 
> 6. There should definitely be an example in IGSTK that demonstrates how to do proper error handling. 
>    This would be of great help to new users.
> 
> Regards,
> 
> Torleif
> _______________________________________________
> IGSTK-Developers mailing list
> IGSTK-Developers at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
> 
>