-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Silently dropped errors in std #28
Comments
It would help to motivate this. What problem are people trying to solve by examining the error returned by Is it possible that those problems can be solved with appropriate use of Note that reading the full man page, |
For me, it's loss of information. Maybe the close fails and then somewhere down the line something else fails as a consequence. Then you have to debug all the way back to this failing close. If you had the error reported at the close itself, it saves all that effort. Also, close is not just for files, but also devices, and devices can be weird. I want to know about anything that goes wrong with a device, as soon as it happens. If this is part of a multi-layered long-lived system, then an occasional close failure could translate to some strange intermittent problem at higher layers. Being strict about logging anything weird really saves time IMHO. |
Concrete examples would be helpful here. As far as I can tell, it is easy to implement this oneself using |
So you're saying that the suggested solution is to bypass 'std' if you want error information from close? Perhaps that should be documented. I have to work with 3rd party serial drivers, some of which can at times be very buggy. However I can't think of an example right now where the error showed up on close. (Although when things go wrong, any syscall including close might lock up the process totally.) With filesystems, you're counting on nothing weird going on. Searching around, AFS could give errors on close, and I suppose any FUSE filesystem might do the same. I guess perhaps that doesn't seem mainstream enough to worry about. It seems strange in Rust to be told (effectively) to be less paranoid and just relax and ignore the errors, when Rust is all about being strict and not letting any failure be ignored. I always check close() return in other languages. But maybe that's not the Rust way. So if no-one else is concerned about this, I'm willing to drop it. |
@uazu I'm asking if this is actually, in practice, a common footgun when developing CLI applications for Rust. This is the CLI working group, so if it isn't, it might be out of scope for this particular WG.
General principles can almost always be used to arrive at any kind of conclusion you want. It is critically important that we focus on real concrete examples, because that's what matters at the end of the day. Certainly, I am not making any general claim that involves being "less paranoid" or "relaxed" about errors. I wish I knew where the discussion on this topic took place was. It was quite in depth. |
OK, I did a bit more searching:
I still feel like there was another discussion I'm missing, but that's what I could find. I think the TL;DR is that we're potentially interested in adding support for something like this, but we need an RFC. |
Okay, I agree this has all been discussed much more comprehensively elsewhere. Thanks for the links. Whilst it affects any CLI tool that works with files or devices, it's not specific to CLI tools. It's not possible to say that CLI tools are simpler so it won't matter, because they may be running as part of a much bigger system. The right thing to do on close failure is probably to report an error to stderr and exit(1), which should end up in some log somewhere if it's being run as part of a larger task. However, this came up in the original thread of #12 because of the general need for queuing not-directly-reportable errors from other sources, which might include ^C handling and also maybe I will close this for now. |
FileDesc::drop
silently drops the error ifclose()
fails. How could we get this error out to the user code? Is there any other code that silently drops errors?One model might be for
std
to keep a (short, fixed) queue of unreported errors globally.FileDesc::drop
could push any error onto this queue. There could be a function for user code to call to check whether there are any pending errors to deal with, and return the error. (This maybe has some overlap with dealing with SIGINT and SIGTERM, when those are being caught.)Any other ideas?
The text was updated successfully, but these errors were encountered: