Re: Reproting (Was Re: Orocos meeting: hotel reservations)

Looking forward to the discussion of the topic.
Cezary

----- Original Message -----
From: <[email protected]>
To: <[email protected]>
Sent: Wednesday, October 23, 2002 10:47 AM
Subject: Reproting (Was Re: [Orocos] 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
>
> _______________________________________________
> Orocos mailing list
> [email protected]
> http://mail.mech.kuleuven.ac.be/mailman/listinfo/orocos