Timeline for Result object vs throwing exceptions
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 24, 2020 at 7:56 | comment | added | chris | @PaulDraper I'm too young | |
| Feb 14, 2020 at 20:20 | comment | added | Paul Draper | "first language that comes to mind" Haskell came to my mind before Rust was even a twinkle. And C as well, though the error paradigms for C are varied. | |
| Feb 13, 2020 at 16:56 | comment | added | gustafc | The nice thing with this approach, is that you can handle result values just like you handle any other value in the programming language - you're not forced to handle an error in the same call stack as it happened. This becomes very handy when you're doing map/flatMap/filter/reduce chains on collections, for example. | |
| Feb 13, 2020 at 16:48 | comment | added | gustafc | @Andy This pattern is commonly used in functional programming languages, too You are generally free to ignore it just like you are free to do nothing in an exception handler. However, APIs tend to be written in such a way that ignoring the return value doesn't make any sense, and you'll generally be using pattern matching (which force you to explicitly propagate or handle) and/or some monadic operations (which will propagate errors nicely). | |
| Feb 13, 2020 at 15:46 | comment | added | Andy | I'm not familiar with rust; what if the result contains an error, does it somehow force you to handle the error if there is one, or can it be ignored? | |
| Feb 13, 2020 at 13:16 | history | answered | chris | CC BY-SA 4.0 |