FAQ
Please don't start caring about that until (a) you have working code that
is too slow/memory-intensive for your needs and (b) you have benchmarks and
profiles that prove that passing around the whole struct is the bottleneck.

Performance is not my first concern - I'm not trying to optimize, I just
would prefer not to return meaningless dummy values, as this can cause bugs
to trickle out and makes things harder to debug... I like the addition of
CanPop() which makes the consumer code more semantic and guarantees early
failure.

Here's the complete code:

http://play.golang.org/p/4uEk5T2lFT
it does look like the kind of thing where I'd expect to see a *Node
passed around, rather than a Node

Yes, it does - it should... I still seem to get confused whenever I start
juggling pointers and methods etc... I'll get there :-)


On Mon, Dec 23, 2013 at 8:43 PM, Caleb Spare wrote:

(Although, after briefly glancing at your larger code sample, it does look
like the kind of thing where I'd expect to see a *Node passed around,
rather than a Node.)

On Mon, Dec 23, 2013 at 7:41 PM, Caleb Spare wrote:

Yes, it does.

Please don't start caring about that until (a) you have working code that
is too slow/memory-intensive for your needs and (b) you have benchmarks and
profiles that prove that passing around the whole struct is the bottleneck.

On Mon, Dec 23, 2013 at 7:26 PM, Rasmus Schultz wrote:

Another way to do it would be to use a named return value.
http://play.golang.org/p/Z9WuVIk1zQ

Oh, that's interesting - but still results in an empty default Node
instance being constructed, doesn't it?


On Mon, Dec 23, 2013 at 8:03 PM, Caleb Spare wrote:
On Mon, Dec 23, 2013 at 6:52 PM, Rasmus Schultz wrote:

I agree with all of that, but I'm stuck with the following:

func (q *NodeQueue) Pop() Node {

if item := q.Queue.Pop(); item != nil {

return item.(Node)

}

return nil

}


I'm not allowed to return nil.


So my only options are, change the method signature to return *Node, which I don't want, for the reasons you explained - or construct and return a "dummy" Node instance whenever there's nothing to return? That seems awfully wasteful.


So I tried this:


const EmptyNode = Node{}


func (q *NodeQueue) Pop() Node {

if item := q.Queue.Pop(); item != nil {

return item.(Node)

}

return EmptyNode

}


Doesn't work either <https://code.google.com/p/go/issues/detail?id=359>.




So my best (only?) remaining option is this:


var EmptyNode = Node{}

func (q *NodeQueue) Pop() Node {

if item := q.Queue.Pop(); item != nil {

return item.(Node)

}

return EmptyNode

}


It doesn't taste right - the EmptyNode really should not be a variable.

Don't worry so much about making this a var. This is fairly common for
types that cannot be consts. For instance, it's used for errors all over:

http://golang.org/src/pkg/net/udpsock.go?s=191:270

For that matter, it shouldn't really exist at all - and yeah, I know, I still need to add an error value to the return statements, but... returning a mutable instance of Node, when in actuality no Node is available - it seems misleading at best, but really, it just seems... wrong.


There's no better way to solve this problem? I mean, this must be a very, very common problem?

Another way to do it would be to use a named return value.
http://play.golang.org/p/Z9WuVIk1zQ
On Monday, October 1, 2012 12:30:01 AM UTC-4, Kevin Gillette wrote:

I disagree with changing the return type from a struct value to a
struct pointer just to have a convenient second indicator (nil) when there
is an error.

1) Use the return type that makes sense when there is no error: if
value copying makes sense on the struct level, please don't use a pointer.
Would you use *byte just to make it nil when there's an error?

2) Anyone calling a function that returns an error should be checking
the error before anything else. If they're not, then as a library writer,
you're not responsible for the consequences. Programmers absolutely should
not be checking for the zero value of the main return type to determine if
there was an "error" condition.

Some good exceptions to #2 are functions like strings.Index, because
not finding the string is not an "error" -- it's a legitimate response to
the question of "what is the index of my substring?" (in this case, the
answer is "none").
On Saturday, September 29, 2012 2:52:02 AM UTC-6, stevewang wrote:

I think the underlying question is what to indicate an invalid
object, so the answer is pointer.

func testreturn() (*Item, error) {
return nil, errors.New("error")
}
On Saturday, September 29, 2012 1:17:30 PM UTC+8, Ji H Park wrote:

Hello there, I'm trying to figure out a way to properly return a
type of nil value but for a struct in a function.

I have a function that returns a struct and error types.

When it runs into an exception, I thought I could use "nil" as
the return value for the struct, but the following error keeps coming up:

"cannot use nil as type Item in return argument"

What would be the proper value to return for the structs when an
exception occurs?

I'd appreciate your help! thanks!

Here's the code:

func testreturn() (Item, error) {
return nil, errors.New("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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2022 Grokbase