"Be strict in what you send, and relaxed in what you receive."
First it was considered a good way to build a robust system. Then HTML and early web browsers came along, took the principle to heart, and everything blew up. (Yes, I'm oversimplifying, but stay with me here.) Now the robustness principle is widely considered a recipe for poor reliability.
I think both stances on the robustness principle are missing a key point.
How can you be sure you actually are strict in what you send, if everything is relaxed about receiving it?
That's the problem with the robustness principle. It's a solid principle when people actually are following it. That is, if they actually are strict about what they send. But without strict receivers, you're not being strict about sending, you're just assuming you are. And your relaxed receiving is encouraging others to be relaxed about what they send, because you're forcing them to assume, too. The result is that the robustness principle is not actually being followed at all.
Strict begets strict, and relaxed begets relaxed. That makes the robustness principle difficult to implement.
There's another issue. "Relaxed" (or "liberal" if you prefer the original wording) is too vague. You want to be relaxed and accept bad input to the point of not dying or corrupting data. But not to the point of encouraging bad input.
What's needed is an amended robustness principle:
Be strict in what you send, and pragmatic in what you receive: Don't crash, but avoid assumptions and speak up about problems.
0 comments for "The [Un]Robustness Principle"
There are currently no comments.