On Sun, Sep 19, 2010 at 01:03:26PM -0700, Daniel Ferguson wrote:
> Can we talk about error handling in code?
> 
> I'm sure error handling is different on the Flight Computer(FC) side than it
> is on the Sensor Node(SN) side.
> 
> Some error scenarios:
> *Logging
> *Try Agains
> *When All Else Fails
> *Ignore
> *Nothing left to try or do
> 
> Some error handling:
> *printf
> *goto
> *struct Exception{...}
> *return ERROR[error_num];
> 
> 
> FC dudes/dudettes:
> What kind of API do you expect, or desire for talking to sensors?
> What kind of error handling do you already have?
> What kind of error handling fits into the FC paradigm?
> What kind of error handling won't fit into the FC paradigm?

Depends on the types of errors and the scenarios we have to deal with.
If we can *avoid* an error entirely, we don't have to deal with it at
all.  For instance, if you never malloc, you never have to worry about
malloc failing (or the OOM killer running).  If you only do so at
program startup time, an error will simply block the ability to launch.
Much of our error handling so far has fallen in that category: avoid
entirely.

Similarly, consider a condition like "logging disk full".  We can avoid
that by just logging circularly somehow, so that we always have the last
$disk_size bytes of log data, and if we run too long we just lose the
rest.

We do plan to have ways to handle errors that we can't avoid, and
obviously we don't want to just abort and go into lawn dart mode, so
we'll attempt to recover when possible.

As far as API for talking to sensors, we plan on a single loop calling
select or poll or similar, and each time we read a sensor measurement
off the wire, we will call a specific function designed to handle that
type of measurement.

- Josh Triplett

_______________________________________________
psas-avionics mailing list
psas-avionics@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics

Reply via email to