I think one of the issues is that Eric deliberately chooses to write his blog in a confrontational style. That is certainly one way to generate a reaction but in my experience confrontation doesn't foster constructive dialog. If you are going to go down the confrontational route then your argument better be 100% waterproof because if it isn't people aren't going to cut you any slack. If they find a hole it's all too easy to be confrontational back and the whole thing spirals.

In this particular case Eric erred by not discussing exceptions that are truly unexpected (i.e. all you know is that your app is in an inconsistent state). At this point human nature takes over and whatever good information was in the original post gets lost in the ensuing dust-up.

I am interested in the strategy that you outlined for how you would do protocol development today using fakes. Is this similar to the Test First Development practices? Do you have some sample code or maybe a new book that explains this in greater detail?

Andrew: Eric, when writing as I.M. Wright, intentionally writes in a confrontational style. In person he is exactly the opposite. He did say he felt a little bad about the possible effect of the column: not that people questioned the size of his brainpan, but the fact that somebody might misinterpret it to mean throw a big try/catch of Exception around all their code.

Sudarshan: No sample or book; it's just the general idea of making your code testable no matter what it does. I would write a loopback network card driver that intentionally dropped packets, duplicated packets, misordered delivery, delayed completion of IRPs, etc under control of my tests (so it would misbehave in a consistent reproducible way). Then I would write a test client to my protocol that sent lots of data back and forth--there is less expectation that a well-behaved client would do "incorrect" things, but it could do 0-length sends, max-length sends, highly fragmented sends, etc again under control of the test, and do similar things on the receiving end. Then I would create a bunch of tests that went through various combos of the two test pieces, and ensure that the protocol always passed all those tests.

- adam

Asserts are not supposed to be used for handling of input, data, user or device errors. Exceptions should handle these.

Assert are supposed to be placed to detect appearance of impossible (internal/logic error) conditions. If the assert() doesn't call the debugger in that state, then what is the point of using asserts at all?

I'm amazed to read that there are developers in MS that think a breakpoint could replace assert().
The problem with breakpoints is that once debugging session is over, they will vanish into the void. If the code is changed after that, the developer may miss newly introduced bug, because the breakpoint that could have detected it is not there.

The stress debugging can't replace asserts(). Actually having full set of asserts() while doing stress debugging could be enormously effective. If you want to catch every bug.

If you just want to bring your code to "working" state and ship it... then I guess asserts are just nuisance.

The funny thing is that I learned how to properly use asserts from 'Writing Solid Code' by Steve Maguire (1994, Microsoft Press).

After reading the original blog, I see that the weight is more on the release/enduser case scenario. Usually asserts are no-op in this case. The blog really rises interesting question. But gives wrong answers.

There is no single correct behavior that would cover all cases.

The right answer is that if program detects internal error condition, it should ask the user what to do.
Abort, Retry Fail. "Send Report" as new option would be improvement.
I think that in the old days Win3.1 had something similar.

The user may have valuable data that he must save. He should know that the data may be corrupt, so he'll save it to another file to recover the important parts later.

Of course in scenarios where we don't have user (aka servers) should behave differently. But that area seems already well developed.

Using a pseudonym does not somehow mean that different rules apply to the standards of argument. It's quite simple, I.M. Wright == Eric Brechner, period. If Eric wants to write in a confrontational style then that's his choice, but those are his words and his ideas, he doesn't somehow get a pass if he is offensive or something doesn't work out how he intended.

There are plenty of confrontational opinion writers in the world, just open any newspaper or current affairs magazine. Unlike Eric they don't try to hide behind a made-up name, they leave that particular rationalization technique to 3 year olds.