On Sunday, October 16, 2016 at 2:20:59 AM UTC-4, Tamás Gulácsi wrote:
> Please check your errors if you depend on the call's success! I.e. if you 
> write into a file, f.Close must be successful, or else maybe it doesn't 
> flush at all, and your file will be empty.

That's a good point, still not the true cause -- checking them will be a 
good practice, but will not solve the problem here, because the exact same 
code works in 
I've verify from the code and result that the save *is* actually working. 

Please take a look at PersistentData-GOB.go 
I assure you it is working. FYC, here is the excerpt:

func main() {

 func test22C() {
 data := &Data{}
 RestoreState("data.gob", &data)
 defer SaveState("data.gob", &data)

 fmt.Printf("%#v\nSave it!\n", data)
 //time.Sleep(5 * time.Second)

 data = &Data{
 ID:      "226622",
 Payload: []byte("foobar"),
 Created: time.Now().Unix(),

If you have run it, you'd know it is working. 
If you have looked at the code, you'd know that the error checking has been 
done, in "test2()". 

The reason that I didn't do it, is because I don't know how to do it. In 
essence, that "f.Close()" that you worried about is wrapped in "defer 
f.Close()" in SaveState, which in turn wrapped in "defer SaveState" in a 
function. I.e., all is happening during the program tear-down phase. If we 
are not planting a "log.Fatal(err)" bomb in SaveState itself, how do you 
think we should check it properly? 


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.

Reply via email to