On Monday, 3 April 2017 16:25:50 UTC-5, Axel Wagner wrote: > The idea that "sometimes" an API call will return values that "may" be >> helpful, or partially useful, is a recipe of disaster. >> > > This is even further from what anyone is suggesting, than the normal level > of misunderstanding on this topic. If anything, the idea is to > *relatively* (!!!)ยน consistently return the most unhelpful value possible. >
Ok, however it's somewhat ironic that this "most unhelpful value possible" is, in your view, an attempt to be helpful. > The idea is to prevent this by putting at least some effort into returning > obviously and intentionally invalid values that blow up immediately. > You cannot predict what a developer will do with any returned value, so it seems pointless to put much effort into making it "obviously" invalid, keeping in mind that in many cases it may not be so obvious. Personally, because it's easy and consistent when writing code, I return the default uninitialized value for the return type. e.g. nil, zero, "", etc. [1] if anyone suggests again that I intend to make this part of an API contract, I'll scream. Ok, so then it doesn't matter what you return, because the user of the API is supposed to check the error. This seems to be universally understood by both parties (API creator & user). Ignore errors at your own peril. -- Kevin Powick -- 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.
