Nick Sabalausky wrote:
I *do* investigate and handle all my warnings before checking code in (note that that's significantly different from warnings being unoptionally coerced into errors by the compiler, because in the latter case I may need to silence a warning because I'm momentarily in the middle of trying to deal with something else). And even if a time constraint requires me to just get it checked in before I can deal with the warnings, I still make damn sure to get around to it (and, to date, I always have). When I investigate a warning, if it turns out to be a problem, then I fix the problem. If it turns out to not be a problem, then I do go and do what I need to halt the warning, *but* it's perfectly fine because *I've already verified there's no problem being covered up*.
You might know that, but the maintainer wouldn't. Furthermore, when such warnings pop up in code you didn't write and don't understand but was dumped in your lap, you'd do what everyone else does in such situations, which is throw in the minimal code necessary to get rid of the warning, and move on.
I agree that a conscientious and careful developer would never do such things. But they do. Even the ones who write articles and books saying "do not do this" will admit to doing it.
When it's convenient and easy to do the wrong thing, people will do it. Even the ones who know better, and promise themselves they won't do it, do it.
The language should be designed as much as possible so that the right thing is the easy and convenient thing to do. Using exceptions for error handling fits right in with that. There's no incentive in D, for example, of doing the Java thing of "swallow and ignore all exceptions."
