func a() {
return
}
func b() {
return a()
}
if a() return no value and b() is returning a() then b() must return no value right 
the Error says that you’re trying to return something but you have nothing to return.
what are you trying to do?
In your case you should write
func a() {
return
}
func b() {
a()
return
}
to be more precise … both return are useless in this case
what you told is right but if we could do that return a() it would like reduce the number of lines.
I am doing these a number of times in my code in my http handlers
(s.close() return no value)
err = json.Unmarshal(data, &pInfo)
if err != nil {
s.close()
return
}
instead I want to write
err = json.Unmarshal(data, &pInfo)
if err != nil {
return s.close()
}
yeah it’s a bit of a stupid question but what is the value of no-value anyway. Why can’t I return no-value value as it won’t be used in further down the call stack?
And ya it is bit clear to use the first one, as it tells the return value of the function and I need not to do further digging to figure out the return value.
to be really honest … I think Go is not the only language that forbids it; I’m quite sure C does it as well.
I understand that you will have 1 less line for each statement like it but … IMHO is a confusing syntax
2 Likes
Any reason why you don’t use defer?
I am conditionally closing the connection. Like if any error occurs then only close the connection.
And if no error occured you leave the connection open in a dangling state?
Either your function is responsible for closing it ultimately, or it needs a way to return it, such that the user can close it once necessary.
In which case also an error should be returned, such that the user can know whether they have to manually close it later or not…
But sometimes closing, sometimes not, really sounds like trouble for future you…
it’s not full code actually. I am working with websockets so I am listening for events in a loop and after loop at the end of function I am closing the connection.
So, as you close it anyway, why not use defer?
Hey C actually allows it (Sorry if I am wrong. I am noob in C).
#include<stdio.h>
void a() {
printf("in a\n");return;
}
void b() {
printf("in b\n");
return a();
}
int main() {
b();
return 0;
}
I tried this and it worked as expected 
.
here’s a brief overview of my code
func joinGame(w http.ResponseWriter, r *http.Request) {
s := newSocket(w, r)
s.once("join-player-info", func(data []byte) {
var pInfo struct {
Name string `json:"playerName"`
Side string `json:"side"`
}
err = json.Unmarshal(data, &pInfo)
// my problem
if err != nil {
s.close()
return
}
})
// this is infinite loop
s.listen()
// after the infinite loop close the socket conn
s.close()
}
This isn’t very well thought true…
This would mean, that you will have a closed s in case of an error, that you will try to listen to, after the s.once() call returned.
That listen will probably fail, as well as the final call to s.close().
Or am I misunderstanding the flow of the code?
what I am actually doing is making a map like map[eventName]eventHandlerFunc and in the infinite loop whenever the event is triggered the event is mapped and the corresponding func is ran.
Writing good code is not about saving a line. Good code should be clear to read.
Your first code sample is very clear. We can see that the function
- calls s.close()
- returns no value
Your second code sample can be confusing to read, as it seems to say:
“return the result of s.close()”
but there is no result to return. A reader would have to look up s.close(), or scroll up to the beginning of the current function, to find out that return s.close() actually returns nothing.
So the first version is much more clear and readable, isn’t it?
Again, saving a line is clearly a non-goal when striving to write clear code.
2 Likes
ya that is what I mentioned in my second reply…I won’t have to waste time digging the return value of the called function. But go is forcing me use the cleaner version 
Ummm… if you already see the first version as clearer, what is exactly the problem? 
Edit: To clarify: what do you dislike so much in the clearer version that makes you want to use less clear code?
ya actually I don’t know what’s bothering me… Maybe I’m overthinking I overthink a lot over small stuff
Happens to me all the time
I’m new in golang but I always thought that you should ‘return nil’ or don’t return anything.
Also after opening the socket, I would use a defer. Once the session is not needed - close it.
If you will need it on multiple places, then why not open the connection and defer it in main() ?
Is my understanding wrong ?
I am using a http connection here. The http protocol is stateless which means the main function is not able to hold any session variables (unless if I use global variables).