Example adds a defer after the error is already returned?

[gregwebs]

I don't understand why the example CopyFile code places os.Remove after os.Create. In the following playground code I moved os.Remove to be after os.Create, and only then do I see the Println invoked and the error altered.

func CopyFile(src, dst string) (err error) {
	defer err2.Returnf(&err, "copy %s %s", src, dst)

	r := try.To1(os.Open(src))
	defer r.Close()

	defer err2.Handle(&err, func() {
		fmt.Println("handled os.Remove")
		err = fmt.Errorf("wrapped %w", err)
		_ = os.Remove(dst)
	})
	w := try.To1(os.Create(dst))
	defer w.Close()

	try.To1(io.Copy(w, r))
	return nil
}

[lainio]

Great question! Sorry for my late reply. I was traveling this week.

Short answer: The err2.Handle with os.Remove is after the os.Create because it's needed only if io.Copy fails. I suppose the cleaning overall exists because the original authors of CopyFile wanted to show how error handling can have parts where resource cleanup is necessary. FYI, all the err2 handlers are called if they exist in the current defer stack at the moment when err != nil. Those handlers are: err2.Annotex, err2.Returnx and err2.Handle.

To be sure, I wanted to test the CopyFile in the current err2 Go documentation. These are the results, and it seems to work as meant to:

• valid source and destination (target) file given no error is generated, and the file is copied successfully.
• when the target file exists, and it's 0400, read-only, the following error is printed:

ERR: copy main.go main.bak: open main.bak: permission denied

Where the main function was:

func main() {
	defer err2.Catch(func(err error) {
		fmt.Println("ERR:", err)
	})

	try.To(CopyFile("main.go", "main.bak"))
}

Unfortunately, I couldn't figure out fastly enough of another way to simulate the io.Copy error but 'mocking' it, i.e., it always returns an error. Anyway, the CopyFile where err2.Handle and its os.Remove is after the os.Create call works as should:

cleaning target file
ERR: copy main.go main.bak2: cannot write file

Where the used mocked Copy function was:

func errCopy(w io.Writer, r io.Reader) (n int64, err error) {
	return 0, fmt.Errorf("cannot write file")
}

And printing the 'cleaning the target' added to err2.Handler.

I hope this helps.

Please note that you can change the first defer err2.Returnf to get a feeling of what's going on. Another tip is that because I don't know how you detect the error in the CopyFile caller and you seem to use %w actual wrapping of errors and CopyFile's first err2.Returnf isn't, you must be careful not to mix them. You could try how err2.Returnw works.

[gregwebs]

Sorry, you are right, the original proposal is doing things that way. IMHO it's not optimal: os.Create could fail and an empty file could be created that would be better off being removed. But it's not something you need to consider as long as your goal is stated as mirroring the proposal code.

[lainio]

You're right that there is that case where os.Create fails and still leaves a file. My personal opinion is that it would still be a bug in the os.Create implementation. At least its current documentation says that the file is ready for writing if it succeeds. My second personal opinion is that every API should be designed by the philosophy of prevent-errors, i.e., offering proper functions for cases like CreateIfNotExist.