I'm on Dave C.'s side with this one. Check the error value. If an error is present, all bets are off with regard to any of the return values. It's simple, explicit and consistent.
The idea that "sometimes" an API call will return values that "may" be helpful, or partially useful, is a recipe of disaster. Yes, some will ignore or forget to check the error value and their programs may continue to work (until they blow up), but this is no different than forgetting to check for a zero value denominator before division. The developer bears some responsibility for the programs they write. If anyone writing an API want's to help the users of their APIs, then provide meaningful, detailed information in any returned error. -- Kevin Powick On Saturday, 1 April 2017 13:12:24 UTC-5, Val wrote: > > Alex, this thread may be lost but please don't give up beyond this thread. > I read all of it and agree 100% to everything you said. > > In short: what you suggest has exactly the same implications and same > benefits as the "often randomized order of map iteration" implementation > detail. I think it is useful and goes in the right direction. > > Val > > -- 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.
