Timeline for Error handling considerations
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 25, 2017 at 4:41 | history | tweeted | twitter.com/StackSoftEng/status/889707176335462400 | ||
| Jul 14, 2017 at 11:04 | history | edited | Adrian Maire | CC BY-SA 3.0 |
added 1135 characters in body
|
| Jul 14, 2017 at 6:09 | comment | added | Adrian Maire | @AmaniKilumanga: I would put it as sort of a meta-target. Should we try it? yes. Is it achievable? Probably not. | |
| Jul 14, 2017 at 4:04 | comment | added | Amani Kilumanga | "[...] or some specific exceptional case is not considered important enough for spending time in developing a solution", does this assume all exceptional cases can be known? | |
| Jul 14, 2017 at 1:08 | comment | added | Mooing Duck | Important data: Phone mms sending failure rate is about 11% due to network reliability. But failing to send an mms is not an indication bug. It's an exceptional case. | |
| Jul 14, 2017 at 0:27 | comment | added | Criticizing Israel not allowed | The main reason I like exceptions is they allow you to catch all unexpected errors from a given block of code and handle them consistently. Yes, there is no good reason the code shouldn't perform its task - "there was a bug" is a bad reason but it still happens, and when it happens you want to log the cause and display a message, or retry. (I have some code that does a complex, restartable interaction with a remote system; should the remote system go down, I want to log it and retry from the beginning) | |
| Jul 13, 2017 at 20:59 | vote | accept | Adrian Maire | ||
| Jul 13, 2017 at 19:12 | answer | added | Matthieu M. | timeline score: 33 | |
| Jul 13, 2017 at 18:53 | comment | added | bash0r | Why not just use something like monads? They make your errors implicit but they won't be silent during run. Actually, the first thing I thought when looking at your code was "monads, nice". Have a look at them. | |
| Jul 13, 2017 at 15:08 | vote | accept | Adrian Maire | ||
| Jul 13, 2017 at 20:59 | |||||
| Jul 13, 2017 at 14:56 | comment | added | Adrian Maire |
Is not that you can ignore them, is that you don't see them: vect.push_back(2) should you catch around that? (yes but you don't know). The idea is to make the need of error catch explicit/obvious (which is not in exceptions/error code). And you can upstream it: just use the provided s. You can also stream it down or forward, which is not the case of exceptions/error_codes
|
|
| Jul 13, 2017 at 14:41 | comment | added | dagnelies | If I understand correctly, your main gripe about exceptions is that people can ignore it (in c++) instead of handling them. However, your Success construct has the same flaw by design. Like exceptions, they'll just ignore it. Even worse: it's more verbose, leads to cascading returns, and you can't even "catch" it upstream. | |
| Jul 13, 2017 at 13:06 | answer | added | utnapistim | timeline score: 15 | |
| Jul 13, 2017 at 12:41 | comment | added | Adrian Maire | Absolutely, I understand and agree on that! It is the purpose of this question to get criticized. And the score of the question to indicate good/bad questions, not that the OP is right. | |
| Jul 13, 2017 at 12:32 | review | Close votes | |||
| Jul 21, 2017 at 10:17 | |||||
| Jul 13, 2017 at 12:17 | answer | added | Useless | timeline score: 46 | |
| Jul 13, 2017 at 12:17 | comment | added | Martin Ba | Upvoted for "This question shows research effort; it is useful and clear", not because I agree: I think quite some of the thoughts are misguided. (Details may follow in an answer.) | |
| Jul 13, 2017 at 11:53 | history | edited | Adrian Maire | CC BY-SA 3.0 |
Added example of use.
|
| Jul 13, 2017 at 11:49 | review | First posts | |||
| Jul 17, 2017 at 1:41 | |||||
| Jul 13, 2017 at 11:45 | history | asked | Adrian Maire | CC BY-SA 3.0 |