FAQ
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