4 ms·

Robust Programming

21 points by gnosis 16y ago

figment 16y ago
one other useful thing to point out. It can often be harder to implement robustness at the bottom of your call chain. You may need to step up a layer. user_method() call_to_get_info_from_remote_system() Just because call_to_get_info_from_remote_system fails doesn't mean you have to be done. user_method(tries) while i < tries if call_to_get_info_from_remote_system() == FAIL # log error if check_remote_system_reachable() # fatal error be done i++ granted this makes all kinds of assumptions like you can afford to retry this operation up to N times. It also may break the rule of "Stupidity"
apu 16y ago
Mostly about C programming, but many of the comments apply equally well when you're writing a library in a higher-level language or a web API. Still, I'm glad not to have to worry about malloc fails, pointer craziness and array overflows anymore, for the most part =)
- corysama 16y ago
  I'll grant you pointer craziness and give array overflows a pass, but I ran into a MemoryError exception in Python just a few hours ago. I loves me some higher-level languages, but they still run on a machine with lower-level limitations.
JoeAltmaier 16y ago
Appropriate for exported APIs; maybe not for internal objects used once by your own code.
andymorris 16y ago
At my last company, I had to code in this style, and it sucks. You get into ridiculous situations where you have to somehow fail gracefully with absolutely no context or information about how to do so. Exceptions are a much better solution - I pity anyone who isn't able to use them. -- Ayjay on Fedang #coding
- wanderr 16y ago
  http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/11816...
lehmannro 16y ago
Assume that the caller or user is an idiot I think this is not helpful at all, probably harmful. There might be use cases for my code I did not even think about and third-party programmers should well be able to use it as they wish. And if they feel like modifying internal state (which the author deems fragile in his article) -- oh well! We are all adults here. NB. I agree that the library he's examining is sub-par quality and is well worth a look.

21 points by gnosis 16y ago

one other useful thing to point out. It can often be harder to implement robustness at the bottom of your call chain. You may need to step up a layer. user_method() call_to_get_info_from_remote_system() Just because call_to_get_info_from_remote_system fails doesn't mean you have to be done. user_method(tries) while i < tries if call_to_get_info_from_remote_system() == FAIL # log error if check_remote_system_reachable() # fatal error be done i++ granted this makes all kinds of assumptions like you can afford to retry this operation up to N times. It also may break the rule of "Stupidity"

apu 16y ago

Mostly about C programming, but many of the comments apply equally well when you're writing a library in a higher-level language or a web API. Still, I'm glad not to have to worry about malloc fails, pointer craziness and array overflows anymore, for the most part =)

corysama 16y ago
I'll grant you pointer craziness and give array overflows a pass, but I ran into a MemoryError exception in Python just a few hours ago. I loves me some higher-level languages, but they still run on a machine with lower-level limitations.

JoeAltmaier 16y ago

Appropriate for exported APIs; maybe not for internal objects used once by your own code.

andymorris 16y ago

At my last company, I had to code in this style, and it sucks. You get into ridiculous situations where you have to somehow fail gracefully with absolutely no context or information about how to do so. Exceptions are a much better solution - I pity anyone who isn't able to use them. -- Ayjay on Fedang #coding

wanderr 16y ago
http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/11816...

lehmannro 16y ago

Assume that the caller or user is an idiot I think this is not helpful at all, probably harmful. There might be use cases for my code I did not even think about and third-party programmers should well be able to use it as they wish. And if they feel like modifying internal state (which the author deems fragile in his article) -- oh well! We are all adults here. NB. I agree that the library he's examining is sub-par quality and is well worth a look.