3 ms·

The error will be ignored, per the docs for File [0]: > Files are automatically closed when they go out of scope. Errors detected on closing are ignored by the

The error will be ignored, per the docs for File [0]: > Files are automatically closed when they go out of scope. Errors detected on closing are ignored by the implementation of Drop. Use the method sync_all if these errors must be manually handled. [0] https://doc.rust-lang.org/stable/std/fs/struct.File.html https://doc.rust-lang.org/stable/std/fs/struct.File.html

josephg 5y ago
That sounds like a weird choice. When do you ever write to a file but not care if the write has failed? Sounds like a source of bugs any time your file system isn’t 100% reliable.
- eptcyka 5y ago
  If you close your files without waiting for fsync to return first, do you really care if the data has hit the disk? If fsync didn't fail, but close fails, what can you do then? Calling close() doesn't imply anything about flushing buffers or syncing data to disk or anything like that. It's just a signal to the OS that your process is done with this particular resource.
  - CraigJPerry 5y ago
    You should probably notify the user though
    - eptcyka 5y ago
      It depends. Regardless, it seems like Go will close file handles for you too, if you've not done it yet, in the finalizer code.
  - ilammy 5y ago
    Also, even if close() fails, you can no longer use the file descriptor anyway, since it might be already reused. The only thing you should do with the error from close() is log it to diagnose why it happened and prevent it next time.
- deathanatos 5y ago
  I agree it's a bit unfortunate. The rub here would be that `Drop` would become fallible, and if it is fallible, then … how does it fail, exactly? (What happens to the error?) There's exceptions, but the downsides to such systems are pretty extensively covered. Nonetheless, the point here is that RAII offers a deterministic close compared to other approaches, at least, even if the write's success isn't covered. You can get that, too, with, wordlist_file.flush()?; or wordlist_file.sync_all()?; depending on desires. (And again, I agree that requiring the programmer to remember code in order to obtain safe behavior is not desirable. But this problem manifests in pretty much any other language, and typically in worse manners.)
  - deleted 5y ago
    [deleted]
- ben0x539 5y ago
  Yeah, it's not an ideal situation. A lot of the time you just read from the file and then you don't really care about the success of close(), though. Maybe that should be a whole set of different types...

josephg 5y ago

That sounds like a weird choice. When do you ever write to a file but not care if the write has failed? Sounds like a source of bugs any time your file system isn’t 100% reliable.

eptcyka 5y ago
If you close your files without waiting for fsync to return first, do you really care if the data has hit the disk? If fsync didn't fail, but close fails, what can you do then? Calling close() doesn't imply anything about flushing buffers or syncing data to disk or anything like that. It's just a signal to the OS that your process is done with this particular resource.
- CraigJPerry 5y ago
  You should probably notify the user though
  - eptcyka 5y ago
    It depends. Regardless, it seems like Go will close file handles for you too, if you've not done it yet, in the finalizer code.
- ilammy 5y ago
  Also, even if close() fails, you can no longer use the file descriptor anyway, since it might be already reused. The only thing you should do with the error from close() is log it to diagnose why it happened and prevent it next time.
deathanatos 5y ago
I agree it's a bit unfortunate. The rub here would be that `Drop` would become fallible, and if it is fallible, then … how does it fail, exactly? (What happens to the error?) There's exceptions, but the downsides to such systems are pretty extensively covered. Nonetheless, the point here is that RAII offers a deterministic close compared to other approaches, at least, even if the write's success isn't covered. You can get that, too, with, wordlist_file.flush()?; or wordlist_file.sync_all()?; depending on desires. (And again, I agree that requiring the programmer to remember code in order to obtain safe behavior is not desirable. But this problem manifests in pretty much any other language, and typically in worse manners.)
- deleted 5y ago
  [deleted]
ben0x539 5y ago
Yeah, it's not an ideal situation. A lot of the time you just read from the file and then you don't really care about the success of close(), though. Maybe that should be a whole set of different types...