Google's Go & Exceptions

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:hjnr0l$1jl5$1 at digitalmars.com...
> 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.

Informing maintainers of things that aren't obvious from the code is what 
comments are for. And yes, yes, yes, comments don't always get made or 
updated, but 1. that's a different issue, and much more importantly, 2. 
there's nothing about DMD's philosophy of warnings that gets around that 
problem anyway.

Sure, D designs things to avoid the need for a warning in the first place, 
whenever possible (and that's great), but the problem is, it's not always 
possible. And for the cases when it isn't possible, and the need for a 
warning does arise, and the original coder gets that warning, verifies that 
it's ok, and then quiets it to prevent future warnings from being overlooked 
in misdst of a pile of old-but-ok warnings (which is exactly what he should 
do in that situation), then we're still right back to "There isn't a damn 
thing that can be done to help the maintainer know that besides hoping an 
approptiate comment was made".

> 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 might be tempted to do that *if* warnings are both fatal and non-optional, 
but other than that, I can't imagine why in the world I, or even any random 
lazy programmer for that matter, would go around blindly silencing non-fatal 
warnings in unfamiliar code. There's no potential benefit in doing that, not 
even a perceived benefit.

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

Yes, that's bad, and it's a problem. But as I already explained, forcing all 
warnings to be either fatal or disabled can do nothing but *encourage* such 
bad practices even *more*.

> The language should be designed as much as possible so that the right 
> thing is the easy and convenient thing to do.

Right, which is why the language/compiler shouldn't make it *more* tempting 
to blindly silence warnings by preventing the programmer from continuing 
their immediate task until all warnings are either hidden (ie turned off) or 
squelched.

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

I absolutely agree with that. The thing I was originally objecting to was 
the idea that GCC's warn_unused_result warning, when used *as* as warning 
(ie, not in a "warnings are/must be treated as errors" context) "may wind up 
suffering similar problems as checked exceptions do". Then I guess I got 
sidetracked on DMD's warnings philosophy.