2016. október 16., vasárnap 22:55:24 UTC+2 időpontban antoni...@gmail.com a
következőt írta:
>
>
>
> 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.
>
> ...
>
> 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()".
>
>
Yes, you're right: I haven't tried or read your code, as the "check your
errors" is not just a basic advice, it's a MUST!
We even have a tool to check that you check all your errors:
github.com/kisielk/errchek :)
And that your unit tests pass means only one thing: your unit tests pass.
It does NOT mean that your production code is correct!
Maybe your unit tests does not reveal the error, as your unit tests does
sth else then the production code.
Maybe different environment, different file permissions, or even different
code paths...
> 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?
>
>
There are several possibilities. Two easy:
1. use a named return parameter:
func SaveState(...) (err error) {
...
// close the file and return the error
defer func() {
if closeErr := f.Close(); closeErr != nil && err == nil {
err = closeErr
}()
...
}
2. Treat the defer f.Close() just as a resource releaser for error path,
and do an "return f.Close()" anyway:
func SaveState(...) error {
...
defer f.Close() // just release resources on error paths
...
return f.Close() // never lose the error of Close!
}
yes, this does call f.Close() twice, and the second (the defer) will error
out, but that does no harm.
> 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.
