3 ms·

>>> f, err := os.Open(blah) // ... defer CheckClose(f, &err) What knowledge do you hope to gain of f.Close fails here?

red_admiral 2y ago
If I understand the OP correctly, if Close() fails then you can't trust that the data was written, even if the previous Write() succeeded.
- randomdata 2y ago
  That's not it. You can't write to a file handle returned by os.Open. https://pkg.go.dev/os#Open https://pkg.go.dev/os#Open func Open(name string) (*File, error) Open opens the named file for reading. If successful, methods on the returned file can be used for reading; the associated file descriptor has mode O_RDONLY. If there is an error, it will be of type *PathError.
- Cthulhu_ 2y ago
  Exactly that; for critical operations like e.g. a database, if a write fails you've got corrupted data and you have a Major Issue. That said, I'm not sure how they would handle a file close failure, wouldn't the file be corrupted anyway because some of the bits may have been written? Then again, at least you can raise the alarms if Close fails, because silent failures are worse than failures.
  - randomdata 2y ago
    > if a write fails. We're talking about a read-only case. os.Open returns a read-only file handle. If you try writing to it, you'll get an error already at that point. If close fails, who cares? > I'm not sure how they would handle a file close failure Ideally there is some kind of failover you can resort to, but if there is no other option at very least you will want to notify a human that what they thought was written isn't actually. But when only reading, you don't need to fall back to anything – all the reads were successful – and what is it to the human? What they thought was supposed to happen did!
    - nightowl_games 2y ago
      I don't know how you can confidently say "if close fails, who cares" all over this thread. If close fails, I wanna know and I wanna know why.
      - randomdata 2y ago
        Let me introduce you to the question mark, seen on your screen as the '?' character. It indicates that a question is asked. This is important as... Never has "who cares" been confidently said. It has always been asked "who cares?". And not asked in a vacuum either, but specifically asked alongside the question of what is to be gained from the knowledge of the error. We now know that you allegedly care, which is a promising start. But you purposefully ignored the other question, which questions the credibly of your care. You can't meaningfully care about something if you don't know why you care about it, and if you knew you'd have told us about it already as it nonsensical to answer to the "who cares?" question alone, so...
        nightowl_games 2y ago
        I care about it because it's unexpected. I seek to wrap my mind as fully as possible around the behavior of my programs. Unexpected behavior like this indicates there is something I do not understand. I cannot rely on my programs if I do not understand them. I cannot state they are robust and stable if I do not understand these sorts of details.

If I understand the OP correctly, if Close() fails then you can't trust that the data was written, even if the previous Write() succeeded.

randomdata 2y ago
That's not it. You can't write to a file handle returned by os.Open. https://pkg.go.dev/os#Open https://pkg.go.dev/os#Open func Open(name string) (*File, error) Open opens the named file for reading. If successful, methods on the returned file can be used for reading; the associated file descriptor has mode O_RDONLY. If there is an error, it will be of type *PathError.
Cthulhu_ 2y ago
Exactly that; for critical operations like e.g. a database, if a write fails you've got corrupted data and you have a Major Issue. That said, I'm not sure how they would handle a file close failure, wouldn't the file be corrupted anyway because some of the bits may have been written? Then again, at least you can raise the alarms if Close fails, because silent failures are worse than failures.
- randomdata 2y ago
  > if a write fails. We're talking about a read-only case. os.Open returns a read-only file handle. If you try writing to it, you'll get an error already at that point. If close fails, who cares? > I'm not sure how they would handle a file close failure Ideally there is some kind of failover you can resort to, but if there is no other option at very least you will want to notify a human that what they thought was written isn't actually. But when only reading, you don't need to fall back to anything – all the reads were successful – and what is it to the human? What they thought was supposed to happen did!
  - nightowl_games 2y ago
    I don't know how you can confidently say "if close fails, who cares" all over this thread. If close fails, I wanna know and I wanna know why.
    - randomdata 2y ago
      Let me introduce you to the question mark, seen on your screen as the '?' character. It indicates that a question is asked. This is important as... Never has "who cares" been confidently said. It has always been asked "who cares?". And not asked in a vacuum either, but specifically asked alongside the question of what is to be gained from the knowledge of the error. We now know that you allegedly care, which is a promising start. But you purposefully ignored the other question, which questions the credibly of your care. You can't meaningfully care about something if you don't know why you care about it, and if you knew you'd have told us about it already as it nonsensical to answer to the "who cares?" question alone, so...
      - nightowl_games 2y ago
        I care about it because it's unexpected. I seek to wrap my mind as fully as possible around the behavior of my programs. Unexpected behavior like this indicates there is something I do not understand. I cannot rely on my programs if I do not understand them. I cannot state they are robust and stable if I do not understand these sorts of details.