Error handling for components (Was Re: OROCOS remarks)

On Wed, 19 Sep 2001, Cezary Zielinski wrote:

[...]
> > A concrete question in this respect from my side: do you think it is
> > sufficient to
> >  (i) design an error mode in each component (and only one
> >      single one, that has to catch _all_ error situations),
> > (ii) return an error code to the user of the component?
> >
>
> The libraries that were designed by us MRROC and MRROC++ used both
> techniques. In MRROC - which utilised procedural approach, each software
> component returned and error code (0 if everything was OK). In MRROC++ each
> component threw an exception. In both cases the main() function was designed
> as a finate state automaton and all errors were dealt with only at the
> uppermost level. This functions well within the scope of a single process.
> In the case of cooperating processes some extra communication has to take
> place - and without an architecture this is not easy to define.

Ok, I see we are really thinking about the same lines: the confusion
was that I was talking about `architecture in the large' (= how should
all components in a robot control software work together), while you
were rather talking about `architecture in the small' (=how does a more
linited set of functionality (=`component' in my terminology) work
together). When I talk about designing components, I really mean both:
desiging the functionality but also the `structure' (=architecture).

One _fundamental_ problem with software engineering (even the
component-based school) is that the composition of two components is
usually not a component anymore; i.e., you cannot just merge the two
interfaces into one, and get a new component. Your example of error
handling is a good illustration of this fact.

So, let me try to summarize: Orocos' mainly concentrates (at this
phase of its existence) onto small-scale-architecture = components. Of
course, always with an eye on later integration into a
large-scale-architecture. It is then indeed unrealistic to expect that
components can be used in any later architecture without modification;
but if they were designed to make their interfaces realistic (= offer
these methods that it can deliver without violating physical
constraints or realism, no less), it will be possible to re-use them.
But of course, some `glue' may be needed. But this is a `software
pattern' (``Facade''), i.e., a mature and well-uderstood technical
issue.

> > Or do you think a more elaborate design is needed. For example, ane
> > dedicated error module for a set of closely cooperating components?
> >
> This is possible, but I am not in favour of that, as this would probably
> give rise to large overheads.

Difficult to predict at this early instant of course.

> Moreover the next set of components would have
> another monitoring thread (or whatever) and some cooperation between those
> monitors would have to be anticipated.

The Facade I was talking about above would be a `solution': we are
really most interested in a ``framwork'' of code instead of in _the_
final, unique and immutable implementation. With `framwork' I mean:
re-using it for a differnt purpose and in a different context may
require some re-coding and re-compilation, but to a limited extent.
This flexibility is of course only possible in Open Source :-)
That's a _very_ big potential advantage that we have with respect to
commercial robot software vendors.

[...]
> We took the view that all the components should degrade gracefully leaving
> the hardware in a safe state. Unfortunately this leads to the whole system
> commiting sucide.

Is this really an unavoidable result? I would look at it more as of a
kind of `hibernation': the components wait to be woken up again,
without having lost their `senses'. But it's too early to forecast
what will be possible in this respect.

[...]
> I meant by simulation that some things may be checked off-line before
> executing the controller software, which incorporates the user program. This
> reports usually only the initially anticipated errors. A more acute problem
> arises when we put together a complete system and it does not function as
> expected - how to find the fault?

I like this remark, because I would insist that every delivered
component has its own testing code, to be used for regression tests
after each update of the whole orocos code. I guess this would be a
quite expensive in the short term, but very useful in the long term.

Again, I think we are basically thinking the same thing but using
other words :-)


Best regards,

Herman