>
> Hi All,
>
> I was going through OCL documentation where a section came on error
> handling. I was trying to look more into error handling (POSSIBLE with
> SOME EXAMPLES)..so that I can see how it is implemented in practice and
> literature explains it nicely but lacked a suitable example whereby errors
> (fatal and user type) can be handled..
>
> Does anyone have any samples on error handling ?

Hi,

The error handling feature is new in RTT 1.4.0 and no OCL components or
examples (in my knowledge) use it yet. Only the unit tests of the RTT use
it, which is of no use to a user. The lacking examples in the manual is a
mistake. However, the 'xyzHook()' error functions are called just like the
other *Hook() functions of the TaskContext.

Here is a very simple use case, which also solves a related socket
question on this list. My TaskContext communicates over a socket with a
remote device. Normally, we get a data packet every 10ms, but sometimes
one may be missing. This is signaled as a run time warning, but we just
continue. When we don't receive 5 packets in a row, we signal this as a
run time error. From the moment packets come in again we go back to run
time warning. Now if the data we get is corrupt, we go into fatal error
mode, as we have no idea what the current state of the remote device is,
and shouldn't be updating our state, as no one can rely on the correct
functioning of the TaskContext.

Here's the pseudo code:

class MyComponent : public TaskContext
{
int faults;
public:
MyComponent(const std::string &name)
: TaskContext(name),
faults(0) {}

protected:
// read the socket with a timeout.
// If ok, process data, otherwise, trigger
// a runtime warning
void updateHook()
{
char* data;
double timeout = 0.02; // 20ms
int rv = my_socket_read(data, timeout);
if (rv == 0) {
this->stateUpdate(data);
faults = 0;
} else {
faults++;
if (faults > 4)
this->error();
else
this->warning();
}

// This is special for non periodic activities,
// it makes the TaskContext call
// updateHook() again after commands and
// events are processed.
this->getActivity()->trigger();
}

// Called instead of updateHook() when in runtime error state.
void errorHook()
{
this->updateHook(); // just call updateHook anyway.
}

// Called by updateHook()
void stateUpdate(char* data)
{
// Check for corrupt data
if ( checkData(data) == -1 ) {
// we will enter the FatalError state.
this->fatalError();
} else {
// data is ok: update internal state...
}
}
};

MyComponent mycomp("MyComp");
// scheduler, priority, execution engine
NonPeriodicActivity myact( ORO_SCHED_RT, 0, mycomp.engine() );

mycomp.start();

Finally, you start this component with a NonPeriodicActivity, which allows
you to wait in updateHook() for as long as you want. Commands and events
are processed when you leave the function,
that's why you can not use a while(1) {} loop within updateHook(), but
re-trigger the activity again
for a next run.

When you want to discard the 'warning' state of the component, call
mycomp.recovered().
If your component went into FatalError, call mycomp.reset() and
mycomp.start() again for processing updateHook() again.

Hope this helps,
Peter