Yeah, we don’t run in debugby Rob Galanakis on 31/07/2011
The danger of making the chk build stricter is that nobody will run it: Here, Raymond mentions how a MSFT team didn’t support running its app in debug mode because it broke into the debugger too much. Hey, let’s report errors only when nothing is at stake!: Raymond talks about programming different behavior into debug and release builds- specifically, to crash in debug but swallow in release.
Perhaps because I haven’t been around too long, I just cannot understand how so many otherwise smart people can have such, such bad ideas. And how common this particular issue is.
The issue was especially bad when I was forbidden to use exceptions. I wanted to put in asserts since I wasn’t allowed to use exceptions, except that no one else used the debug build, so when people broke these asserts, they never knew. And then when people’s changes broke some new (and pretty fundamental) asserts, I was told ‘oh, we don’t run in debug.’
Wait, what? You have absolutely no way to ensure valid state, or even keep track of state at all, other than in logs that make debugging far more difficult than it should be (because the problem that should have asserted or crashed will only manifest itself much later and it is unlikely you can determine where the state got messed up by just looking through the log, at least without adding a bunch more logging).
Does your studio do this (not run in debug because there are too many exceptions or asserts)? If so, you may need to smack sense into people. This is a god awful and unforgivable practice when you are using any program- programs with persistent state can corrupt that persistent state, and programs without state can return unexpected results. These sort of decisions are indicative of a myopic or insular culture that is in serious need of a rude exposure and shake firstname.lastname@example.org