From IGSTK

Error Event Management

Problem: IGSTK lacks a consistent strategy for Error management via Events

Suggested Approach:

Survey the current Event Hierarchy (done - see below)
Propose a new hierarchy where a base IGSTKErrorEvent is introduced (pending)

Torleif's comments

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.
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?
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?
In any case, it should be clearly documented (doxygen) which events a component may emit in response to requests.
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.
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.

Event Hierarchy Survey2

The diagrams below illustrate a current survey (April 16th 2008) of the event hierarchy in IGSTK. The first diagram shows the current event hierarchy. The second diagram shows the proposed event hierarchy. Both diagrams were generated using this event hierarchy diagram code.