Google's Go & Exceptions

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:hjnidq$s0p$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> It it were an error (or treated as an error or a D-style "warning"), then 
>> yes. But as a true warning, not so much.
>
>
> Many shops require that warnings be treated as hard errors.

In which case it's no longer a "true warning", so that doesn't really affect 
what I said.

Besides, if a shop does make that a hard-and-fast requirement, then by doing 
so they are the creating the situation you described of causing programmers 
to hide problems in code without verifying first that it's not actually a 
problem. So a compiler like DMD obviously doesn't do a damn thing to change 
that. In fact, it just encourages that scenario in not just those shops, but 
in all the other ones as well. Sure, those other shops could just leave 
warnings off, but then you're recreating the scenario where the warnings 
become background noise, except it's worse because nobody even has a chance 
to pay attention to them.

> Furthermore, a warning that is not an error tends to become ignored 
> background noise over time. (The infamous Windows Vista permission box is 
> a fine example of that.)

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*.

Any time any coder compiles their code and sees a stream of white noise 
warnings, that should be a red flag that they're approaching development 
wrong. Now yes, that *does* happen, and many coders *do* ignore that stuff, 
and yes, if there is something we can do to improve that situation without 
causing additional problems, then we should. But DMD's approach *doesn't 
actually do a damn thing to improve the situation*. In fact, it just 
*encourages* it:

DMD's philosophy with warnings: It's bad to go blindly covering up warnings 
because they might be indicating a real problem, and it's bad to ignore your 
warnings as white noise for the same reason. Therefore, we should provide 
the user with two options: Use "-w" to be forced to silence the warnings 
before proceeding, and thus be provided with *more* motivation/temptation to 
blindly cover them up, or omit "-w" to make it even easier to ignore all 
warnings.

Ie, all the problems you've identified with warnings are valid concerns, but 
DMD's "solution" clearly exacerbates those problems rather than alleviating 
them.