7 comments

[ 2.4 ms ] story [ 33.6 ms ] thread
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"

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 =)

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.
Appropriate for exported APIs; maybe not for internal objects used once by your own code.
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.