This is a very refreshing article and a must read.
I work in embedded products. It is remarkable how there are long enumerations of error codes, nested together, munged, one enum chaining after another. Complexity.
You think "wow, this must be important stuff". Only to find that all errors are either ignored or wrapped in some (god-dammed) macro that resets the device when an error occurs. Like this:
#define CHECK_RESULT(error_code) \
do { assert(error_code == SUCCESS) } while(0)
Having engineers read and take notice of this article should is worth the time and thought process in order to avoid brain-dead nonsense as seen above and in so many products.
Happily and timely, we have design discussions for the new products starting this week. A perfect means for promoting thoughtful, consistent and useful errors and how they might be handled.
Yes, at first the multiple errors seem like a good idea, but then something screws them up. Somebody misuses a code, the code is lost in propagation, or it replaces and hides another failure.
Most likely the error code distignuished the errors at some point. But then a defect was discovered. More error codes were checked. Repeat. Eventually somebody just decided that it'd be easier to just handle any error the same way. It may not be optimal, but it had the best chance of working consistently.
It's not the type of error that decides how to handle it, it's where and when it occurs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is a very refreshing article and a must read.
I work in embedded products. It is remarkable how there are long enumerations of error codes, nested together, munged, one enum chaining after another. Complexity.
You think "wow, this must be important stuff". Only to find that all errors are either ignored or wrapped in some (god-dammed) macro that resets the device when an error occurs. Like this:
#define CHECK_RESULT(error_code) \
do { assert(error_code == SUCCESS) } while(0)
CHECK_RESULT( send_packet(packet) );
CHECK_RESULT( recv_packet(&packet) );
Having engineers read and take notice of this article should is worth the time and thought process in order to avoid brain-dead nonsense as seen above and in so many products.
Happily and timely, we have design discussions for the new products starting this week. A perfect means for promoting thoughtful, consistent and useful errors and how they might be handled.
Yes, at first the multiple errors seem like a good idea, but then something screws them up. Somebody misuses a code, the code is lost in propagation, or it replaces and hides another failure.
Most likely the error code distignuished the errors at some point. But then a defect was discovered. More error codes were checked. Repeat. Eventually somebody just decided that it'd be easier to just handle any error the same way. It may not be optimal, but it had the best chance of working consistently.
It's not the type of error that decides how to handle it, it's where and when it occurs.