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 https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go. I've verify from the code and result that the save *is* actually working. Please take a look at PersistentData-GOB.go <https://github.com/suntong/lang/blob/master/lang/Go/src/ds/PersistentData-GOB.go>, I assure you it is working. FYC, here is the excerpt: func main() { test0() test22() test1() test2() test22() test22C() } ... 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? Thanks -- 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.
