Timeline for Result object vs throwing exceptions
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 19, 2020 at 15:27 | comment | added | Snackoverflow | I believe this to be the correct approach and the accepted answer in general. I would love to hear any counter-arguments or examples where this could not be applied. | |
| Feb 26, 2020 at 20:00 | audit | First posts | |||
| Feb 26, 2020 at 20:00 | |||||
| Feb 23, 2020 at 18:58 | comment | added | dgmstuart |
I do a lot of Ruby/Rails stuff and I basically agree with this interpretation: as an example: a service object called UserCreator, which is expected to return an object which represents the user which was created. If the user wasn't created, then a common approach is to return nil or false, or a result object which responds to a success? message with false but contains no data. All these approaches involve returning different-shaped responses (/different types) in different cases. Better to return an object of one shape, and to raise an exception if that's not possible.
|
|
| Feb 21, 2020 at 0:47 | comment | added | Andy | @PaulPalmpje Well, that's not really the point of my answer, which is why i said its a different take and not "exceptions only for exceptional reasons," and we have a few answers along those lines already, I just wanted to provide a different perspective which I think is also valid. Of course you don't need to agree. | |
| Feb 20, 2020 at 21:07 | comment | added | Paul Palmpje | @Andy Yes. I agree in part. Mostly my view is that exceptions are just that. You can expect a login to fail and the consumer process should handle that in a normal way. Expanding this a bit... the login method should return a state value and only throw in really bad circumstances. | |
| Feb 20, 2020 at 20:58 | comment | added | Andy | @PaulPalmpje My answer is based in the semantics of the method name and what the method name implies. Login should throw if its not able to put the system into a logged-in state. But that doesn't mean you can't create a TryLogin method that returns a true or false based on the result. But you might still need to handle exceptions from a TryLogin; what if the system can't log you in b/c your app is in maintenance mode (and you need to tell users that)? Now false is "bad user/pwd" or "system in maint." or "i don't know what went wrong." | |
| Feb 20, 2020 at 20:02 | comment | added | Paul Palmpje | I have to disagree on the last part of the answer. Login should be able to fail without an exception. Just as lottery tickets will not always win the login could 'win' or 'loose' or maybe invalid (but catching say empty input would be part of the frontend). Exceptions only when the connection to the login validation process fails. | |
| Feb 18, 2020 at 3:08 | comment | added | Wes Toleman |
@Andy, yes that's exactly the distinction. Avoiding exceptions for me isn't about exceptions vs return codes (which you can enforce to some degree in some languages with attributes like [[nodiscard]]). It's more about turning turning run-time issues into compile-time errors and making it impossible to represent invalid states. Some exceptions are inevitable however. Philosophically, I don't like the scoping issues try/catch introduces and the longjump nature of exceptions isn't much different to goto yet it seems to get a free pass in that regard.
|
|
| Feb 18, 2020 at 1:59 | comment | added | Andy | @westoleman Exceptions were created for a good reason; you can ignore return codes, you can't ignore exceptions (without crashing). In my thinking Login would put the state of the app into an authenticated state but Validate wouldn't. For that reason i think Login should throw in invalid creds (since it cant put the app in the expected state) but Validate could return true or false since you're only asking if the creds are valid. Does that match your thinking? | |
| Feb 18, 2020 at 1:21 | comment | added | Wes Toleman |
@Andy, I've been mulling it over, maybe the distinction isn't as important as I first thought. I have a bias against exceptions so I try to engineer them out. Login logs in or excepts, ValidateCredentials validates credentials (returning a bool or some sort of credential validation result) or excepts. In the case of validation the only exceptional case is "I don't know because I couldn't reach the credential store" rather than anything to do with the input itself.
|
|
| Feb 16, 2020 at 16:55 | comment | added | Andy | @WesToleman I'm not sure I follow; what do you think the Login method looks like vs ValidateCredentials? | |
| Feb 16, 2020 at 2:42 | comment | added | Wes Toleman | It took me a little while before I understood what you were saying about the Login method. I think your answer would benefit if you compared it with a method to validate credentials. | |
| Feb 15, 2020 at 16:38 | comment | added | john16384 |
I like this, as it isn't based on how rare the exceptional case might be. It also means that a short method name like pay should have exceptions declared on it for insufficient balance or invalid account, or it should be named payIfSufficientBalanceAndAccountValid with an appropriate result type detailing the final result.
|
|
| Feb 13, 2020 at 16:51 | comment | added | StackOverthrow | @canton7 Method names are almost never sufficient documentation. Contracts should be documented in doc comments or the language's equivalent. | |
| Feb 13, 2020 at 15:37 | history | edited | Andy | CC BY-SA 4.0 |
added 12 characters in body
|
| Feb 13, 2020 at 15:30 | comment | added | Andy | @canton7 Excellent way of wording it; I wish there were more emphasis on contracts. I'll edit your wording into my answer. | |
| Feb 13, 2020 at 15:29 | history | edited | Andy | CC BY-SA 4.0 |
added 12 characters in body
|
| Feb 13, 2020 at 9:29 | comment | added | canton7 | Absolutely. Another way of wording this is "The method is unable to fulfil the contract established by its name". If the method's name says that it will validate the lottery ticket, it should show an exception if it is unable to fulfil that contract: if it is unable to validate the lottery ticket. Then of course you have the discussion around what "validate" actually means in your domain... | |
| Feb 13, 2020 at 0:45 | history | answered | Andy | CC BY-SA 4.0 |