I never return a broken value with an error because there are occasions where returning both a value and an error make sense, such as a partial read. More than anything else, I'd rather make it clear that this is not one of those cases so I don't confuse myself later when I'm trying to track down a bug.
On Fri, Mar 31, 2017 at 5:02 PM, 'Axel Wagner' via golang-nuts <golang-nuts@googlegroups.com> wrote: > > > On Sat, Apr 1, 2017 at 1:50 AM, Dave Cheney <d...@cheney.net> wrote: >> >> >> >> On 1 Apr 2017, at 10:41, Axel Wagner <axel.wagner...@googlemail.com> >> wrote: >> >> So… Given that I'm not talking about modifying any contract - see a) in my >> previous message - but just making an effort that I'm not contractual bound >> by, I am not sure how I am supposed to read this. Is this an argument for >> not being helpful? Because I don't quite see how your point invalidates >> that. Or is it an argument for being hurtful? Which I also don't really see, >> as I'm not talking about any change in contract. >> >> Like, I legit starting to doubt my sanity here; I don't see how I can >> actually be any clearer about how I do not intend to change anything about >> the "if a non-nil error is returned, assume the returns are invalid" rule. >> The question is "how is it hurtful, if I then also add an extra layer of >> defense against people violating that contract"? >> >> >> But why? Why encourage people to be reckless. IMO this is difference >> between map ordering during iteration being undefined, which it is, rather >> than guaranteed to be random, which is not. > > > Great point. Why does gc implement it that way, then? And does it hurt, that > gc implement it that way? The contract does not contain anything about the > iteration order, so why did we add that code and CPU time to explicitly > randomize it, instead of just letting buggy code be buggy and blow up at > some point with hard to debug errors? This seems to be essentially the > argument you are making, so why does it, seemingly, not apply to randomized > map iteration in gc? > >> >> >> Both are contracts with the same result to the casual user -- map >> iteration is unpredictable, but by not guaranteeing that the order will be >> random, it prevents people relying on the side effect. >> >> This is the argument I'm making now, yes, you could go to effort to make >> sure that some of the values you return are nil so that they explode as soon >> as someone forgets to check an error, but you probably shouldn't because >> >> A, this is providing a stronger contract than necessary. > > > No, it is not. The contract is the same. I'm sorry to be a stickler here, > but I really don't see why this point is so elusive. I am not suggesting > adding a "if an error is returned, the other return values will have their > zero value" to my godoc. > >> >> B, it encourages people to be clever and try to avoid the error checking >> idiom. > > > I legit don't see how, given that this is not a rule. I also don't do it > with any kind of strictness that would allow people to rely on it. > >> >> C, doesn't work for all return values, only the pointer shaped ones. > > > I disagree. An empty string or a 0 or whatever is *still* a much more > telling symptom to debug than *some* string/integer/whatever, especially if > it's an invalid value (and if it isn't; why is would we even talk about it). > > But anyway, yes, I mostly do this with pointers, but *so what*? Why throw > the baby out with the bathwater? Again, this is not part of any API. This is > not an all or nothing thing. This is a safety net for people coding bugs and > it's totally fine if it is there sometimes and not there at other times (and > you even argue yourself that it shouldn't, to "keep people on their toes"). > >> >> >> >> >> Are you trying to say that I'm training them to not adhere to the >> contract? Because I don't see how; it's blowing up either way, just, in one >> case the blowup might be easier to detect and debug. >> >> I respect your opinion and I do agree, but we just seem to be talking >> about different things… anyway. Sleep, for now. >> >> On Sat, Apr 1, 2017 at 1:09 AM, Dave Cheney <d...@cheney.net> wrote: >>> >>> I think the simpler contract is to give no guarantee whatsoever of the >>> state of the other return values in the presence of an error. >>> >>> It's a simple, clear, and most importantly consistent contact. >>> >>> To guarenteed that in the presence of an error the values that can be >>> respresented by nil _will_ be nil is less consistent, and more importantly >>> encourages people to not check error by substituting their own ad-hoc tests >>> like testing if a return value is nil, implying an error. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
