avr-libc-corelib
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]