4 ms·

Maybe I'm not understanding this, but you're saying that you should only ever return success or failure from functions but then you're also throwing exceptions?

Maybe I'm not understanding this, but you're saying that you should only ever return success or failure from functions but then you're also throwing exceptions? how do these patterns reconcile with this railroad programming style in the video?

chriswarbo 4y ago
THe introduction talks about throwing, but the rest of the text is about returning Success and Failure values. It's probably just a poor choice of terminology in the intro.
- vlovich123 4y ago
  It’s about adapting methods that throw out of your control. For example, I/O or timeouts in JS (presentation is language agnostic).
mcluck 4y ago
I don't understand what that paragraph is on about. I use this approach extensively and the whole point is that you don't need exceptions anymore. LogRocket is a service that kind of counts on errors being thrown so maybe there's something there haha
pryelluw 4y ago
The spirit of the idea is to be explicit about what is the behavior you can expect from the code. You can’t foresee every exception, but you can at least make an effort to handle those that are likely to happen. It allows the calling code to handle the exception in a way that it doesn’t kill the program unless necessary. You can recover from some exceptions and should if possible. Note that it took me a bit of getting used to the idea due to my background with python. Its type system does require a lot of extra code to implement this pattern.
thdc 4y ago
Yes, extremely confusing article imo. The use of promises and async await allow the unhandled rejections to bubble up, but they've put "Success" else "Failure" in their pseudocode which could be interpreted as a return (wouldn't bubble up without extra code in the callers) or a throw (would bubble up) - not filling in that part leaves too much room for interpretation as does using async await everywhere unless you are already somewhat familiar with what they're driving at. My understanding of what's trying to be conveyed would be better explained by using something like the Result type in Rust paired with the ? operator (failures are returned early/bubble up but successes go through). They should have slapped together a result type in Typescript to get the point across. Similarly in go you have multiple returns and the common `if err != nil { return err }` a billion times which I think is the same concept here, just much more verbose. How does that differ from the initial code in tfa? I'd say it's because the caller returns the callee's failure rather than constructing its own thing or continuing with logic. Then there's also some monad discussion that I'm not fully qualified to give.
ilyt 4y ago
The idea is that instead of checking error after every call you just throw exception and handle it above but article is just plainly bad.

chriswarbo 4y ago

THe introduction talks about throwing, but the rest of the text is about returning Success and Failure values. It's probably just a poor choice of terminology in the intro.

vlovich123 4y ago
It’s about adapting methods that throw out of your control. For example, I/O or timeouts in JS (presentation is language agnostic).

mcluck 4y ago

I don't understand what that paragraph is on about. I use this approach extensively and the whole point is that you don't need exceptions anymore. LogRocket is a service that kind of counts on errors being thrown so maybe there's something there haha

pryelluw 4y ago

The spirit of the idea is to be explicit about what is the behavior you can expect from the code. You can’t foresee every exception, but you can at least make an effort to handle those that are likely to happen. It allows the calling code to handle the exception in a way that it doesn’t kill the program unless necessary. You can recover from some exceptions and should if possible. Note that it took me a bit of getting used to the idea due to my background with python. Its type system does require a lot of extra code to implement this pattern.

thdc 4y ago

Yes, extremely confusing article imo. The use of promises and async await allow the unhandled rejections to bubble up, but they've put "Success" else "Failure" in their pseudocode which could be interpreted as a return (wouldn't bubble up without extra code in the callers) or a throw (would bubble up) - not filling in that part leaves too much room for interpretation as does using async await everywhere unless you are already somewhat familiar with what they're driving at. My understanding of what's trying to be conveyed would be better explained by using something like the Result type in Rust paired with the ? operator (failures are returned early/bubble up but successes go through). They should have slapped together a result type in Typescript to get the point across. Similarly in go you have multiple returns and the common `if err != nil { return err }` a billion times which I think is the same concept here, just much more verbose. How does that differ from the initial code in tfa? I'd say it's because the caller returns the callee's failure rather than constructing its own thing or continuing with logic. Then there's also some monad discussion that I'm not fully qualified to give.

ilyt 4y ago

The idea is that instead of checking error after every call you just throw exception and handle it above but article is just plainly bad.