Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

On Tue, 2017-04-04 at 18:41 -0700, utyughj...@mail.com wrote: > case in point: https://play.golang.org/p/p7WtbMZj3O Why would you return a newly allocated [c]byte pointer in fooSTUPID instead of nil? That is *not* doing what is suggested, but rather returning a more likely valid and usable

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

https://www.reddit.com/r/golang/comments/62cupa/is_it_idiomatic_to_return_a_badly_structured/ the example given by the OP is faulty. here is a play illustrating the possible misunderstanding of the OP or typos by the OP: https://play.golang.org/p/rt31qb9EiH but even so, the argument given by

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

There are cases in the standard library that explicitly intentionally return, or leave, invalid values in cases when they should not be used. This being the generalised case of this question. One of the clearest examples (others don't necessarily have comments) of this is in go/types/initorder.go

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

On Tue, Apr 4, 2017 at 5:18 PM, Joubin Houshyar 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 >> wrote: >>> >>> Well, you've got bigger fish to fry here in your

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

On Tue, Apr 4, 2017 at 12:38 AM, Joubin Houshyar 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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

(btw, I'm obviously still reading this thread :) Thanks for the replies) On Mon, Apr 3, 2017 at 11:25 PM, Axel Wagner wrote: > Hi, > > On Mon, Apr 3, 2017 at 11:02 PM, Kevin Powick wrote: > >> Check the error value. If an error is present, all

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

Hi, On Mon, Apr 3, 2017 at 11:02 PM, Kevin Powick wrote: > 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. > I've said it at least 5 times in this thread alone but: No one is

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

Hey Axel, this is a good question that I've thought about from time to time as well. It seems that most people in this thread have misunderstood it :) I personally agree with your preference as given in the examples just because I find the code easier to read when the error return is handled

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

A former customer made it a practice to always return properly initialized objects where others would return nul/null. Instead of exploding in dev, the programs merely behaved mysteriously at run-time. In a libray which called it, had to check everything I was passed for *meaningfullness*,

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

A former customer made it a practice to always return properly initialized objects where others would return nul/null. Instead of exploding in dev, the programs merely behaved mysteriously at run-time. In a libray which called it, had to check everything I was passed for *meaningfullness*,

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

My 2 cents: On Saturday, April 1, 2017 at 4:26:20 AM UTC-7, Axel Wagner wrote: > > Ian: > Re your question: See my example given above (or the one below, which is > probably more authentic). For example, you might be allocating the returned > struct, and piece by piece filling in the fields. If

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

On Saturday, 1 April 2017 22:26:20 UTC+11, Axel Wagner wrote: > > Ian: > Re your question: See my example given above (or the one below, which is > probably more authentic). For example, you might be allocating the returned > struct, and piece by piece filling in the fields. If there can be

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

On Saturday, 1 April 2017 22:26:20 UTC+11, Axel Wagner wrote: > > Ian: > Re your question: See my example given above (or the one below, which is > probably more authentic). For example, you might be allocating the returned > struct, and piece by piece filling in the fields. If there can be

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

> On 1 Apr 2017, at 11:02, Axel Wagner wrote: > > > >> On Sat, Apr 1, 2017 at 1:50 AM, Dave Cheney wrote: >> >> >>> On 1 Apr 2017, at 10:41, Axel Wagner wrote: >>> >>> So… Given that I'm not talking about

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

On Fri, Mar 31, 2017 at 3:33 PM, 'Axel Wagner' via golang-nuts wrote: > > there recently was a thread on /r/golang, about whether or not to explicitly > return useless values when an error occurred, or to just not care, as the > caller isn't supposed to use a return

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

On Sat, Apr 1, 2017 at 1:50 AM, Dave Cheney wrote: > > > On 1 Apr 2017, at 10:41, Axel Wagner > 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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

> On 1 Apr 2017, at 10:41, Axel Wagner 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

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

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_

Re: [go-nuts] Is it harmful to always return invalid values on a non-nil-error?

I agree (as I said). But that wasn't the question. The question was, whether it is hurtful, for me, as the author of a function, to a) not give that guarantee, but b) still do my best do return obviously blowing up values (under the assumption that the users of my packages, me included, are not

[go-nuts] Is it harmful to always return invalid values on a non-nil-error?

My position is the caller cannot make any assertion about the state of the other values returned until they have checked the error. If the error was non nil then nothing can be said about the state of the other values returned. -- You received this message because you are subscribed to the

[go-nuts] Is it harmful to always return invalid values on a non-nil-error?

Hey gophers, there recently was a thread on /r/golang, about whether or not to explicitly return useless values when an error occurred, or to just not care, as the caller isn't supposed to use a return value on a non-nil value anyway. So, say, I have a type that wraps an *os.File (or a database