Timeline for Improved input validation function
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 17, 2023 at 12:01 | vote | accept | globalturist | ||
| Oct 17, 2023 at 5:31 | answer | added | Jakkapong Rattananen | timeline score: 0 | |
| Oct 15, 2023 at 15:24 | answer | added | globalturist | timeline score: 1 | |
| Oct 14, 2023 at 10:05 | comment | added | globalturist | @indi ohh now I see! Il rethink the solution and answer on this post | |
| Oct 13, 2023 at 20:58 | comment | added | indi | To fix the cppreference code, just remove the else on line 19, then move lines 17 and 18 into the if block (and indent them correctly to silence the warning/error). Now it works; it always accepts good input, always rejects bad input, and never loses good input. The lesson is simple and clear: “always check for “fail” first… then check for anything else (EOF or “bad”). If the fail bit was not set, then you have valid input, period, no matter what the EOF or bad bits are. | |
| Oct 13, 2023 at 20:58 | comment | added | indi | The problem, as I have repeated no less than three times now, is that you are doing it wrong. You are throwing away valid input because you are not checking for “fail” before checking for “EOF”… which even the code you keep pointing to does. This means you are throwing an error when there is no error, and losing perfectly valid input. The cppreference code is also wrong. I can prove it. Just click “run this code”, then edit line 11 to remove '\n', then run. Look at the output. Note how it’s changed. The “2” is now lost. | |
| Oct 13, 2023 at 10:35 | comment | added | globalturist | @indi that's why I throw a StreamFailure and not just call exit if the user believes its recoverable he can catch the exception and recover. I just don't see the problem if you have the option to just catch, take care of it (log it or whatever) and recover. Also, it may not be right but cppref I linked does do the check like I do (eof and bad together else fail else success) granted it is on a stringstream but it should be the same for all istream objects | |
| Oct 12, 2023 at 20:06 | comment | added | indi | (As an aside, your interpretation of the bit you quoted is incorrect in another way. The quote says “… [t]his is something that std::cin.clear() can’t fix…”, so you conclude “[b]ased on that, its not a recoverable error”. That is wrong. You can recover from EOF. What the text says is just that clear() can’t do that. That is true; clear() (alone) cannot fix EOF. But it’s still trivial to fix.) | |
| Oct 12, 2023 at 20:06 | comment | added | indi | What @panik says is correct, but it’s even worse; you’ll get a stream failure error even if the file is not empty and contains valid data… all you need is no trailing newline. You are misreading that tutorial. Look closer. It does check for EOF… only after checking for failure. (It should also check for “bad”, but… 🤷🏼.) The key word in your quote that you are not processing is “subsequent”: “… which causes all subsequent input operations to fail”. It does not (usually) cause the current input operation to fail, because EOF is not an error. Always check for fail first. | |
| Oct 12, 2023 at 10:31 | comment | added | globalturist | @panik In my previous comment I explained the reason and I think it does warrant stream failure. Also, you can catch the StreamFailure and send a message to stderr about the error (read the stream state in the catch block and inform exactly the kind of failure) so a user of the program will be informed about the error. On the other hand not treating it as an error will just brick your program which is a way worse alternative IMO. | |
| Oct 12, 2023 at 10:19 | comment | added | globalturist | @Zeta Its comments that I wrote in for the reviewers because on the last post people made remarks about them so I'd like to save some typing to anyone that's interested in helping | |
| Oct 11, 2023 at 20:34 | comment | added | panik | @globalturist Consider the following example. It is quite common to connect a file to the standard input like this, $./validate < in.txt. I get StreamFailure if the file is empty. The signal does not explain the reason of the particular error and, as a user, I feel punished for no reason. Maybe we should not consider the eof stream state as an error at all. | |
| Oct 11, 2023 at 18:19 | comment | added | Zeta | Are those your actual comments? Or are those comments for reviewers? If it is the latter, please remove them, keep the code as-is. If those are actual comments, then I have some review notes for them. | |
| Oct 11, 2023 at 8:02 | comment | added | globalturist | If you read the learncpp article I added you would see this quote: "On Unix systems, entering an end-of-file (EOF) character (via ctrl-D) closes the input stream. This is something that std::cin.clear() can’t fix, so std::cin never leaves failure mode, which causes all subsequent input operations to fail.". Based on that, its not a recoverable error like extraction failure and is indeed a StreamFailure. | |
| Oct 10, 2023 at 23:37 | comment | added | panik | We should not throw StreamFailure for the empty stream. It is more like the extraction failure. | |
| Oct 10, 2023 at 14:53 | history | edited | Toby Speight | CC BY-SA 4.0 | Spelling and grammar |
| Oct 10, 2023 at 14:11 | history | asked | globalturist | CC BY-SA 4.0 |