On Tue, Apr 4, 2017 at 5:18 PM, Joubin Houshyar <jhoush...@gmail.com> wrote:
> > > On Tuesday, April 4, 2017 at 2:34:29 AM UTC-4, Axel Wagner wrote: >> >> On Tue, Apr 4, 2017 at 12:38 AM, Joubin Houshyar <jhou...@gmail.com> >> wrote: >>> >>> Well, you've got bigger fish to fry here in your example above than >>> worrying about call site snafus: you should be closing that opened file in >>> the error case. Right? >>> >> >> I don't think so. First, from a "general go API hygiene" position, it >> doesn't make sense to require to do *anything* to a returned value if a >> non-nil error is returned. And second, if open(2) fails, there won't even >> be anything returned that could be closed. >> >> It seems to me neither Dave's (roughly: all bets are off if function >>> returns error) nor Ian's (roughly: be extra hygienic) replies has satisfied >>> you. >>> >> >> I don't know how you would come to that conclusion. Dave's messages >> didn't satisfy me, because they did not actually have anything to do with >> the question. Ian's reply did. He asked a follow-up question though, which >> I answered. >> >> But also, I wasn't asking for a question with an authoritative answer. I >> was soliciting opinions. That kind of thing doesn't usually end once >> someone gave theirs. And I find all the other (later) replies very useful. >> >> >>> And as far as the being "hurtful" to users of your functions, if they >>> are ignoring errors, and ignoring documentation, then they fully deserve >>> spending a few extra cycles banging their heads against the wall. It a >>> lesson worth learning. >>> >> >> This is an incredibly weird position to me. The reasons for not checking >> an error might range from "they don't have the experience/knowledge" to >> "they weren't careful enough at that time" and considering either to be >> deserving of punishment seems very arrogant to me. It seems to say that you >> assume both you always were an expert programmer and you never make any >> mistakes. >> > > Punishment is something that is meted out. Self inflicted pain is not a > form of punishment. Learning any craft entails making mistakes and learning > from those mistakes. For example, there is not a conspiracy of nail and > hammer makers to "punish" novice carpenters who miss the nail and hit their > fingers with the hammer. It is just part of the learning process. > We still do not use the parlance "they deserve it" in that case. And, honestly, if I could give them a hammer that would make it harder or less painful if they hit themselves, I'd consider it a cruelty to not give it to them just to satisfy my own elitism. Again, I intentionally asked for harms of doing this. Obviously, if there is significant downside, it can be debated whether it's worth it. But that wasn't the statement; the statement was, that people who do not adhere to the documentation, deserve the pain of a bug that's hard to track down. Which is a position I do not understand and that I consider actively harmful to tech-culture. Making people's life easier when they made a mistake - even if it's their >> fault - is a net positive; you lose nothing and their life gets easier. >> > > In this context, making people's life easier is adhering to language > conventions, and providing correct documentation and bug free > implementations. > I obviously disagree. Not with the sentiment itself, but that doing this means anything else is not worth doing, much less counterproductive. (p.s. I did not appreciate the pejorative terms in your reply. You may wish > to review this document: https://golang.org/conduct) > Feel free (publicly or privately, whichever you prefer) what specifically you are referring to and how I could have framed the same sentiment within appropriate conduct (or why you consider the sentiment itself to be inappropriate). -- 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.
