Timeline for Result object vs throwing exceptions
Current License: CC BY-SA 4.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 5, 2023 at 15:26 | comment | added | iperov |
I don't like traditional exception definition. an error occurred (e.g. the ticket is invalid) but caller must know about this exception for example EInvalidTicket. So if caller knows about all exceptions, they are no longer exceptions, because caller catch EInvalidTicket and processes this situation, which is similar to return a Tuple with nullable value and error enumeration.
|
|
| Nov 23, 2022 at 7:28 | comment | added | Wilko van der Veen | So how does this work when there is middleware involved? As a developer I dont know which middleware is injected which can throw exceptions, can we assume all middleware should add its exceptions as an item to a result? | |
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot |
Commonmark migration
|
|
| Feb 20, 2020 at 23:45 | comment | added | LB2 |
I'd argume that "Invalid Ticket" (as in bad values such as out of range numbers, expired date, bad scan etc) does seem like an exception and in many languages function do throw ArgumentOutOfRange or ArgumentFormat-like exception to indicate exactly that. That's exactly what good and secure programing practices dictate - validate function input validity and in case of invalid input to reject processing the call (i.e. often by throwing exception, language and stylistics dependent).
|
|
| Feb 15, 2020 at 15:04 | comment | added | Dave Nay | This distinction is something I have been struggling with this week with gRPC. It strongly feels to me that gRPC is using exceptions for program flow. | |
| Feb 14, 2020 at 1:37 | comment | added | mtraceur | The "define errors out of existence" heuristic suggests that in many cases, "invalid ticket" might just be "did not win". The "do not leak information unless you know it is secure (and if your first reaction is 'how can it be not secure?' you don't know if it is secure)" heuristic also suggests that unless there is a good reason otherwise, an "invalid ticket" should produce the same result to the user as "did not win". UI / UX best practices suggest that in both "did not win" and "invalid ticket" cases, if manual entry was involved, prompt the user to double check if they entered it right. | |
| Feb 13, 2020 at 12:04 | comment | added | Rohan Bhale | 'It all depends on what cases you are planning to support', so crucial to this answer. If confused go back to your requirements. | |
| Feb 13, 2020 at 8:56 | comment | added | bracco23 | @CaiusJard In that case, I guess you would design the interaction to avoid checking the ticket if there is no connection. IMHO it all boils down to the actual task you want to perform and the preconditions you set that must be verified. Return values communicate legit outcomes when preconditions are satified, exceptions communicate when the preconditions are broken. (e.g. I assume °I have connection to check the ticket, but I do not assume the ticket is valid yet) | |
| Feb 13, 2020 at 0:16 | comment | added | HappyDog | @JoshPart - You can code for them by writing an exception handler. Throwing exceptions doesn't mean "not coding for" - it means delegating the decision about how to code for them to the calling code. The lottery ticket checking function has no idea what the most appropriate response is for handling 'unable to connect' errors - that may be several layers higher, maybe even all the way to the user ("Unable to connect - try again?"). Better to throw an exception so that the appropriate layer can pick it up without the intervening layers needing to do anything special. | |
| Feb 12, 2020 at 21:43 | comment | added | Josh Part | @CaiusJard while I do agree that "unexpected situations" might not be the correct way to describe them, I would also argue that neither is "reasonable to code for". Exceptions should be about things that happen that are outside of the scope or the normal functioning of the process. Yes, it might be reasonable to expect the server to be down, but "being down" is not part of the functions the server should do. | |
| Feb 12, 2020 at 20:53 | comment | added | Ben Cottrell | @CaiusJard My thinking on that topic would be around separation-of-concerns between core/domain logic and logic around the "boundaries" related to infrastructure/OS/APIs/etc. I think it's important to make a clear distinction between validation in domain data/logic versus failures/errors happening in external dependencies. Even if infrastructure failures are expected, I would still regard them as "unexpected" from the domain point of view. Exceptions are useful because they unwind the stack without the domain logic needing to care, whereas domain logic probably does care about bad data. | |
| S Feb 12, 2020 at 18:39 | history | suggested | Toby Speight | CC BY-SA 4.0 |
Spelling fixes
|
| Feb 12, 2020 at 18:10 | comment | added | Caius Jard | (You cover this in "cases you're planning to support" but "unexpected situations" isn't, to me, necessarily the flip side of that coin) | |
| Feb 12, 2020 at 18:08 | comment | added | Caius Jard | Oh, it wasn't a criticism, it was more that your last sentence said "what are unexpected situations" whereas I'm advocating that it may not be so much about expected/unexpected, it's about reasonable-to-code-for/unreasonable-to-code-for - I can fully expect the lottery server being unavailable, but the judgement call of whether to code for it (or any of the other hundred things I can "expect" to go wrong) or not is the threshold of "how much defense for situation X do we want to go to the effort of writing". | |
| Feb 12, 2020 at 17:27 | comment | added | Caius Jard | Ahh but then one could argue that "because the shop is in a remote location with flaky cell/net coverage, not being able to contact the server is every bit as expected an error as the user typing in an invalid ticket number etc.." and so it goes on, down into the navel fluff of every possible thing. I would thus say it's not so much about unexpected conditions, but about only covering for a reasonable number of conditions before one reaches the point of throwing the towel in.. | |
| Feb 12, 2020 at 17:05 | review | Suggested edits | |||
| S Feb 12, 2020 at 18:39 | |||||
| Feb 12, 2020 at 13:24 | comment | added | gnasher729 | "Server performing the ticket validation is down" would be an exception. Well, we hope it's an exception :-( | |
| Feb 12, 2020 at 11:57 | history | edited | helb | CC BY-SA 4.0 |
added 4 characters in body
|
| Feb 12, 2020 at 10:18 | comment | added | helb | @BenCottrell Well, my example for an error case may not be the best, see the "Addendum" section. | |
| Feb 12, 2020 at 10:17 | history | edited | helb | CC BY-SA 4.0 |
added 410 characters in body
|
| Feb 12, 2020 at 10:15 | comment | added | Ben Cottrell | Surely 'Invalid ticket' would be a normal part of validation and therefore something which should be expected rather than an error per-se. For example, a user could quite legitimately present the system with the wrong barcode, type the wrong ticket number, enter the number for an expired ticket, enter a number for a ticket which has already paid out winnings, etc. Unexpected errors would be things like network failure or a back-end service becoming unavailable | |
| Feb 12, 2020 at 9:41 | vote | accept | dumazy | ||
| Feb 12, 2020 at 8:59 | history | answered | helb | CC BY-SA 4.0 |