Reproting (Was Re: Orocos meeting: hotel reservations)

On Wed, 23 Oct 2002 [email protected] wrote:

> You mentioned that reporting is a problem. I agree to that. Although MRROC++
> has not solved the problem completly it is not at all bad in that respect.
> The system is divided into separate processes. Each process can be viewed as
> a finate state automaton. Within each "state" of the automaton some actions
> are performed that can lead to abnormal situations that have to be reported.
> In that case an exception is thrown and subsequently caught at the uppermost
> level (the automaton level). From there the report is sent to the System
> Response Process (SRP) that visualises the message on the screen. Standard
> status messages can also be sent to the SRP, but here you can do it from any
> level of the process structure. After reportiing an error the automaton is
> being reset to a state that it can handle new commands (dialogue with other
> processes). It should be noted that after throwing an exception it can be
> caught at some intermediate level and handled adequately. In that case the
> exception does not reach the uppermost level, thus the remedied problems are
> not reported - unless necessary. The programmer is free to either use the
> general method or to override it with local remedies. I think that something
> similar could be used within the OROCOS project. We can talk about that at
> the meeting.
 
I'm looking forward to it!
We still remember the emphasis you've put on exception handling during
previous Orocos meetings, and we have not forgotten about it :-) So,
Peter Soetens will present our current design, whose functionality is
not too different from what you describe. The design problem, however,
is with making sure that _everything_ in the whole framework uses a
coherent reporting interface.

Herman