[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Avr-libc-corelib] Error handling
From: |
Jan Waclawek |
Subject: |
[Avr-libc-corelib] Error handling |
Date: |
Mon, 21 Sep 2009 23:27:48 +0200 |
Error handling is always a topic a typical programmer wishes to avoid or to
postpone as far as it gets. Moreover, as in typical embedded systems there's
usually little or no user interaction, it's always a question, what exactly can
we do in case of a run-time error.
A library-maker has a slightly better position. The easiest thing to do in a
library - besides ignoring them, of course :-) - is to throw them to the
caller's head. This is most probably what we are going to do here, so this
makes errors an inevitable part of the API, isn't it. And, as errors may occur
maybe within every module of a library, it might be worth to establish a common
policy how to handle them.
A common thing to do is to return an error flag if a function fails to perform
as intended. This seems to be fine and consistent, but... 1. often, the
programmer implicitly assures that error won't occur (e.g. communication is
throttled by the other party well enough to prevent buffer overflow), so he
ignores the returned error; 2. maybe even more often the returned error is
ignored even if it is not quite kosher to ignore it, simply for lack of any
reasonable action to take in case of error; 3. if the function is called for
example from an ISR, there's really nothing to do with an error but to store it
for further use - which is what the called function might have done straight
away; 4. some of the functions have better information to return than an error
code.
Ergo, IMHO it's a pure waste to return runtime error codes, and I suggest to
establish a single variable, core_lib_error or such, where functions could
store an appropriate code when error occurs, and leave it upon the user how
does he wish to use or ignore it.
We can also define a "first wins" or "last wins" strategy, a set of
standardized error codes and a header full of predefined strings to spit out in
case an appropriate output device is available; but those are only less
significant details.
Comments?
JW
- [Avr-libc-corelib] Error handling,
Jan Waclawek <=