Timeline for Result object vs throwing exceptions
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 20, 2020 at 7:23 | comment | added | Codebling | @Clockwork-Muse it may be worth using the words checked and unchecked in your answer | |
| Feb 12, 2020 at 23:56 | comment | added | Clockwork-Muse | @supercat - Files being unreadable (whether due to byte twiddling or just a wrong text block) is an anticipable error. If that means your application can't process that file any further, then don't do so (or stop the program). Otherwise, if you're trying to lock the file such that other programs can't read it, that's usually poor behavior. | |
| Feb 12, 2020 at 23:24 | comment | added | supercat | ...cases where code that uses a token completes normally (implying the lock should be released) and cases where it exits via an exception (implying that if the token was acquired for writing, the lock should be invalidated such that all pending and future acquisition attempts fail instantly). Unfortunately, without a provision for that, distinguishing between recoverable and unrecoverable failures will be very difficult. | |
| Feb 12, 2020 at 23:21 | comment | added | supercat |
If code is trying to parse an integer which is going to be valid unless an input file is sufficiently corrupted as to render any attempts at parsing meaningless, there's really not much benefit to having the parser's immediate calling code try to handle a parse fail gracefully. Unfortunately, existing languages' exception mechanisms are poorly adapted to distinguish between scenarios where a function fails without adverse side effects, and those where failure could leave an object in a corrupted state. Proper Dispose handling for things like lock tokens should distinguish between...
|
|
| Feb 12, 2020 at 19:11 | history | answered | Clockwork-Muse | CC BY-SA 4.0 |