Timeline for Result object vs throwing exceptions
Current License: CC BY-SA 4.0
43 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 21, 2020 at 23:46 | comment | added | The Muffin Man |
So basically your language has a built in standard mechanism for reporting unexpected behavior (exceptions), but you think returning a domain specific object is a valid choice? While you're at it why don't you just use character arrays instead of strings.
|
|
| Feb 19, 2020 at 18:15 | review | Suggested edits | |||
| Feb 26, 2020 at 12:44 | |||||
| Feb 19, 2020 at 14:52 | history | protected | gnat | ||
| Feb 19, 2020 at 14:28 | answer | added | Thomas van den Bighelaar | timeline score: 1 | |
| Feb 19, 2020 at 10:02 | comment | added | Peppe L-G |
@BenCottrell, Happy Path means that nothing unexpected happens - for example, locked files on disk, database exceptions [...] - I don't see the difference. If you know these things can happen, then they're not unexpected? They're rare, but not unexpected. So the question is rather how rare must a thing be to be thrown as an exception instead of being handled as a return value?
|
|
| Feb 15, 2020 at 11:57 | answer | added | Thorbjørn Ravn Andersen | timeline score: 4 | |
| Feb 14, 2020 at 13:10 | comment | added | Sebastian Redl | As noted, this is very language-specific. Some languages don't have exceptions at all. Some do, but still prefer not to use them. | |
| Feb 13, 2020 at 21:47 | answer | added | FluidCode | timeline score: 1 | |
| Feb 13, 2020 at 21:43 | comment | added | Frank Hopkins | @BenCottrell Nope, a happy path is a single path, typically understood to be the most simple most common path that is expected to go through without error or exception being thrown / required to be handled. It is ONE path, not all that go through, and there may be additional alternative paths that also run without exception. See for instance Wikipedia: "In use case analysis, there is only one happy path, but there may be any number of additional alternate path scenarios which are all valid optional outcomes." en.wikipedia.org/wiki/Happy_path | |
| Feb 13, 2020 at 17:22 | comment | added | displayName | Related question, asked on SO, and my answer. | |
| Feb 13, 2020 at 13:16 | answer | added | chris | timeline score: 9 | |
| Feb 13, 2020 at 12:57 | answer | added | CharonX | timeline score: 0 | |
| Feb 13, 2020 at 12:32 | comment | added | Paul D. Waite | It's in the context of JavaScript (specifically Node.js), but there's a decent discussion of handling different types of errors here: joyent.com/node-js/production/design/errors | |
| Feb 13, 2020 at 12:24 | comment | added | curiousdannii | Does this answer your question? Return magic value, throw exception or return false on failure? | |
| Feb 13, 2020 at 10:48 | comment | added | Eric Duminil | @Matthew: It seems to be the exception used by casinos when they don't feel like shelling out $42 million. | |
| Feb 13, 2020 at 10:38 | comment | added | el.pescado - нет войне | ... If continuing makes sense even though there's some exceptional situation, use other error handling mechanism. | |
| Feb 13, 2020 at 10:37 | comment | added | el.pescado - нет войне | @MikeSeeds What typically happens if an exception is not handled? Program termination. I consider that a feature. Often, when something exceptional happens there's no point in continuing. When you want to cook spaghetti and discover that you don't have pasta is there any reason to boil pot of water? No, the correct action is "program termination". The essence of raising of exception is cancelling subsequent operations. If a failure means that there's no point in executing subsequent actions, raise an exception. | |
| Feb 13, 2020 at 8:32 | comment | added | Polygnome | Winning or not winning or both expected states of validation of a lottery ticket, none of those two is exceptional. | |
| Feb 13, 2020 at 0:45 | answer | added | Andy | timeline score: 53 | |
| Feb 12, 2020 at 22:31 | comment | added | Izkata | @AntP Correct, in some places it's even built in at a very fundamental level | |
| Feb 12, 2020 at 22:01 | answer | added | Eric Lippert | timeline score: 75 | |
| Feb 12, 2020 at 19:46 | answer | added | Paul Draper | timeline score: 18 | |
| Feb 12, 2020 at 19:11 | answer | added | Clockwork-Muse | timeline score: 3 | |
| Feb 12, 2020 at 18:35 | review | Close votes | |||
| Feb 18, 2020 at 3:05 | |||||
| Feb 12, 2020 at 18:06 | comment | added | Matthew |
Ironically, does this mean if you build a lottery system and you win the lottery, you should throw a LotteryWonException, because you never expect to win?
|
|
| Feb 12, 2020 at 18:00 | history | tweeted | twitter.com/StackSoftEng/status/1227653773461512200 | ||
| S Feb 12, 2020 at 17:53 | history | suggested | helb |
replaced tag "authentication" with "error-handling" to better match question.
|
|
| Feb 12, 2020 at 17:21 | comment | added | Mike Seeds | What typically happens if an exception is not handled? Program termination. Do you want statements that can cause program termination littered throughout your code? There are two different types of non-happy paths. Sad and Bad. Exceptions should only be used on the 'bad' path. The example you provided i.e invalid login is a sad path and should be handled without using exceptions. In most languages use of exceptions to handle sad path cases would be considered bad form. | |
| Feb 12, 2020 at 16:48 | comment | added | R. Schmitz | ericlippert.com/2008/09/10/vexing-exceptions | |
| Feb 12, 2020 at 16:32 | history | became hot network question | |||
| Feb 12, 2020 at 16:27 | review | Suggested edits | |||
| S Feb 12, 2020 at 17:53 | |||||
| Feb 12, 2020 at 13:22 | answer | added | gnasher729 | timeline score: 3 | |
| Feb 12, 2020 at 12:13 | answer | added | Phill W. | timeline score: 3 | |
| Feb 12, 2020 at 9:41 | vote | accept | dumazy | ||
| Feb 12, 2020 at 9:15 | comment | added | dumazy | Alright, thanks a lot. I think it whether or not you have control of the thing definitely plays part in this. This cleared things up a bit for me | |
| Feb 12, 2020 at 8:59 | answer | added | helb | timeline score: 89 | |
| Feb 12, 2020 at 8:49 | comment | added | Ben Cottrell | @dumazy - invalid credentials for an app connecting to a framework or API endpoint isn't the same as a user typing their username and password incorrectly. The difference is whether user input validation is involved. Users generally wouldn't be entering credentials for an app to connect to an API, but they would be typing their credentials for logging into their social media account or online banking for example. In other words, it's important to consider the origin of the thing you're checking and whether you can control or trust that source | |
| Feb 12, 2020 at 8:49 | history | edited | dumazy | CC BY-SA 4.0 |
Corrected based on comments
|
| Feb 12, 2020 at 8:48 | comment | added | Ant P | This question is somewhat language specific though, iirc Python encourages use of exceptions in normal control flow. | |
| Feb 12, 2020 at 8:47 | comment | added | Ant P | @dumazy 401 is an HTTP response status code. Not an application exception. They are two very distinct concepts. Users entering incorrect passwords is not an exception scenario. | |
| Feb 12, 2020 at 8:46 | comment | added | dumazy | True, I took a wrong turn with the lottery example. I'll add an edit to the post about it. Although I'm not sure if I agree with invalid credentials being part of the happy path. Looking at a few frameworks, they all tend to throw exceptions for invalid credentials. Even HTTP standards suggest "throwing" a 401 Unauthorized. | |
| Feb 12, 2020 at 8:38 | comment | added | Ben Cottrell | "the happy path would be that you won" -- No, that's not what the term happy path means. A losing ticket is very much 'happy path' because it's a scenario you should expect to handle in the business logic. Happy Path means that nothing unexpected happens - for example, locked files on disk, database exceptions, network interruptions, internal errors in 3rd-party libraries or API, expired certificate, etc. User auth is the same - a user's invalid username or password is also Happy path. In fact, any kind of user input validation is 'happy path'. | |
| Feb 12, 2020 at 8:26 | history | asked | dumazy | CC BY-SA 4.0 |