Google's Go & Exceptions

[Walter Bright]

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