You need to close it and check for errors as part of the happy path. But it's great that in the error path (be that using an early return or throwing an exception), you can just forget about the file and you will never leak a file descriptor.

You may need to unlink the file in the error path, but that's best handled in the destructor of a class which encapsulates the whole "write to a temp file, rename into place, unlink on error" flow.

Any fallible cleanup function is awkward, regardless of error handling mechanism.

Java solved it by having exceptions be able to attach secondary exceptions, in particular those occurring during stack unwinding (via try-with-resources).

The result is an exception tree that reflects the failures that occurred in the call tree following the first exception.

I often miss this feature in other languages. It has saved me more times than I can count.