Timeline for Error handling considerations
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 18, 2017 at 9:32 | comment | added | Useless | @8bittree true, but using Maybe for error handling (by continuing to execute statements that will no longer do anything, and have to explicitly take a Maybe, and pattern-match the do-nothing case) reproduces the part of OP's implementation I wanted to avoid. I probably explained that poorly though. | |
| Jul 14, 2017 at 0:36 | comment | added | Criticizing Israel not allowed | "There must be free space" can be a precondition for the happy path, but to cover all cases, the correct postcondition for the entire operation must rather be "either there was insufficient free space or the file was created". (Because of race conditions, you can't say that there is insufficient free space). | |
| Jul 13, 2017 at 17:43 | comment | added | 8bittree | @Useless C++17 actually includes the closely related Option/Maybe monad. | |
| Jul 13, 2017 at 17:37 | comment | added | ShreevatsaR | @Useless IMO for quality software, it does make sense that “every place you might create a file, you need to prompt the user to fix the situation and retry”. Early programmers often went to remarkable lengths towards error-recovery, at least Knuth's TeX program is full of them. And with his “literate programming” framework he found a way to keep the error-handling in another section, so that the code remains readable and the error recovery gets written with more care (because when you're writing the error-recovery section, that is the point and the programmer tends to do a better job). | |
| Jul 13, 2017 at 17:30 | comment | added | 8bittree | @Useless Lazy evaluation has nothing to do with the use of the Error monad, as evidenced by strict evaluation languages like Rust, OCaml, and F# that all make heavy use of it. | |
| Jul 13, 2017 at 17:18 | comment | added | Bart van Ingen Schenau |
@AdrianMaire: The "allowing to fail gracefully and be re-run" could also be implemented as showing the Save dialog again along with an error message and allowing the user to specify an alternative location to try. That is a graceful handling of a problem that can't typically be done from the code that detects that the first storage location is full.
|
|
| Jul 13, 2017 at 14:18 | history | edited | Useless | CC BY-SA 3.0 |
added 366 characters in body
|
| Jul 13, 2017 at 13:22 | comment | added | Useless |
Your solution means that every place you might create a file, you need to prompt the user to fix the situation and retry. Then every other thing that might go wrong, you also need to somehow fix locally. With exceptions, you just catch std::exception at the higher level of the logical operation, tell the user "X failed because of ex.what()", and offer to retry the whole operation when and if they're ready.
|
|
| Jul 13, 2017 at 12:55 | comment | added | Adrian Maire |
Thanks to your answer, it add light to the topic. I guess the user would disagree with and allowing my program to fail gracefully, and be re-run when he just lost 2h work:
|
|
| Jul 13, 2017 at 12:24 | history | edited | Useless | CC BY-SA 3.0 |
deleted 1 character in body
|
| Jul 13, 2017 at 12:17 | history | answered | Useless | CC BY-SA 3.0 |