On Thu, 12 Nov 2009, Sylvain Joyeux wrote:

> On Thursday 12 November 2009 07:46:00 Herman Bruyninckx wrote:
>> On Wed, 11 Nov 2009, Sylvain Joyeux wrote:
>>> On Wednesday 11 November 2009 20:09:52 Herman Bruyninckx wrote:
>>>>> Example: if my motor driver module tells me "I'm in a very bad shape",
>>>>> I'll route around that module and shut down the power line.
>>>>
>>>> What you should be doing is _interpreting_ the 'error condition', and
>>>> recover from it, not 'work around' it...
>>>
>>> That's what I do. I do not work around the error, I work around a buggy
>>> component to avoid having him break my system (and what is around it).
>>
>> That's just postponing the problem one stage further :-)
> Don't get what you mean here.

I mean that I do not see exactly what this "workaround" can solve: you
still have to "recover" from the error, don't you? And if a component is
really buggy and should be "worked around", this can only(?) happen by
activating a redundant component that can take over the functionalities of
the component-in-error...?

>>>> I do restate my statement, in a somewhat different way: "components can
>>>> not be in an "error state", but only in a _computation_ that (tries to)
>>>> deal with a non-nominal situation". In still other words: as long as the
>>>> component can still perform computations, it should (itself!) give
>>>> _meaning_ to the non-nominal state, and send corresponding data and
>>>> events to the other components. If it can not continue working, it
>>>> should go to the "inactive" state, and not to an error state.
>>>>
>>>> Errors are (almost? always?) a property of _data_ in the
>>>> component/system's "world model", and not of their "state". So, there is
>>>> really no reason to introduce error states; the problems have to be
>>>> solved via "world model error computations" instead! And those
>>>> computations can be done in the normal active state of a component.
>>>
>>> Yes and no. Components should not have to deal with all the cases in the
>>> world.
>>
>> Indeed not: only with those parts of the world they are responsible for, or
>> knowledgable of.
> *Even* in that part of the world they may not be able to handle every cases.

Of course. Sometimes (too often in current practice!:-)) our software
systems can only give up...

>>> A good system is IMO a set of specialized components that is properly
>>> articulated by a supervision system. Error states is a way to tell the
>>> supervision that there is a discrepancy between what the component can
>>> handle and what the world is.
>>
>> Error _events_ are appropriate, yes, but error states should only come in
>> when everything else fails. And that's really very late into the problem
>> chain!
> Well. Having developped an event based system for supervision. I should maybe
> agree.
>
> It happens that what I learned by using it is that events and states are most
> of the time dual representations. The former is a "situation calculus"
> representation and the latter more a "markovian" one (not exactly in both
> cases, but let's say these are the formal frameworks the nearest).

They are near, indeed. But for me they are sufficiently semantically
different in order not to confuse them :-)

> In other words, to decide what to do, you both look at what happened *right
> now* and what happened *earlier*. States are then just a way to aggregate the
> history into an appropriate compact representation.

This is what I called the "(computation) status" in a previous email! In
systems and control theory, this "memory of what happened before" is also
called the "state", leading to most of the semantic confusion that we are
implicitly also victim of in this thread :-(

In the context of Coordination ("supervision"), the state is the discrete
state of the FSM that defines what Computations to execute in this FSM
state.

>>> But in that case, I fully agree with you, the component *must* send back
>>> a specialized error report to the supervision (not just "error").
>>>
>>> Now, let's get real: code is *buggy*. Funnily enough, you are using the
>>> same argument as my former PhD advisor: if there is a bug in the code, it
>>> is the fault of the code writer and the framework should not have to deal
>>> with it.
>>
>> That's _not_ what I claim :-) I claim that components should use error
>> _events_ much more, instead of going to error _states_.
> I don't competely agree. Most of the time, if an error event needs to be sent
> it also means that you enter a special case for computation, and is therefore
> in a specialized state ... that someone could boldly call an error state.

This _could_ an _internal_ state of the Computation! And it is not
necessarily true that this internal state has to be externalised to all
other components!

>>> I don't even want to get as near as one km of a robot that has been built
>>> with such a design rule. So ... what is the problem with buggy code ?
>>> Well: you *can not know what it is doing*.
>>
>> Same answer as a above: I advocate a somewhat less traditional way of
>> handling errors.
> It is not as non-traditional that you think it is. Look at situation calculus
> for instance.

Situation calculus is, as far as I remember, not traditional in control
_software_ design, is it? :-) At least in the engineering curricula that I
know about all over Europe. (France could be an exeption, since it has a
much more formal tradition than the rest of Western Europe :-))

>>> One way buggy code manifests himself is by having assertions raising
>>> exceptions in the libraries ... i.e. consistency checks saying "not
>>> consistent !". That is what I propose to get that information back to the
>>> supervision system here. And the only way you can do that is by telling
>>> it "well, something is wrong, but I don't know what".
>>
>> Exceptions are a rather C++-centric thing, which I think undermines
>> deterministic handling... So, they should be avoided.
> I could not disagree more ;-). Exceptions have appeared in most high-level
> languages for a very good reason and they should be used.

Correct me if I am wrong, but the semantics of exception handling have
never been "done right" in any language, at least not for the purpose of
deterministic execution...

>>>> Lazy component developers have been the cause of so many "error state"
>>>> designs in the past (and present...), but all of them are design errors.
>>>>
>>>> :-(
>>>
>>> If by that you mean "having only one generic error state", yes, I agree.
>>> If you mean "a well structured error representation", you are completely
>>> wrong (but given what you said before, I think you are in the first
>>> case).
>>
>> I am certainly in the first case :-) But I don't understand your second
>> case... :-)
> Well, that errors needs to be categorized and "structured" in order to allow
> appropriate responses by the supervision layer. Read my thesis for more
> details ;-)

Ok, I got what you mean! I think that I would prefer the term "semantic
definition" to what you "structured categorization", but that's not really
that important... :-)

Herman