4 ms·

I mean if your opinion is "somewhere up the call stack, you're handling that exception" and "if you don't, the framework will 500" means you're not pretending n

by bedobi 3y ago

I mean if your opinion is "somewhere up the call stack, you're handling that exception" and "if you don't, the framework will 500" means you're not pretending nothing can go wrong, then we will never agree, because I absolutely would characterize both of those as pretending nothing can go wrong, at the very least in context at the function call site. As for your code example, again, that is not analogous to the functional style. The functional style is you have an Either object no different to any other object. You do not if on the object, you do not early return the object in the sad case etc etc. Just throw all notion of all that out the window. You just pass it around without doing anything, or, if you only wanna do something in the happy case, you send in what to do using map, and then keep passing it around. There is zero requirement to handle the error like you seem to imply. Only at the outermost layer do you handle the error, and only if you wish to do so. (if you don't, just fold it into a 400 or 500 or whatever)

hot_gril 3y ago
> I absolutely would characterize both of those as pretending nothing can go wrong, at the very least in context at the function call site Agreed that within the function call site I'm pretending nothing can go wrong, but not within the entire program. I don't see what's unsafe about that. We're just now implying that anything can return an error instead of restating that fact every time, and instead you have to be explicit about catching it. About the functional programming... you're saying there's no if-else or early return in functional programming, but Erlang, a functional programming language, has if-else and exceptions ("throwables") that look like Java: https://learnyousomeerlang.com/errors-and-exceptions https://learnyousomeerlang.com/errors-and-exceptions. Under the hood it's one logical chain like you said, but we're using a lot of syntactic sugar on top. > if you only wanna do something in the happy case, you send in what to do using map, and then keep passing it around That's the kind of if-else early-return I mean, and it's probably what you want to do if you aren't using exceptions. My C++ code also (explicitly) passes the error around, albeit not in the functional way. In like 99% of the cases you are just passing the error up.

by bedobi 3y ago

hot_gril 3y ago

> I absolutely would characterize both of those as pretending nothing can go wrong, at the very least in context at the function call site Agreed that within the function call site I'm pretending nothing can go wrong, but not within the entire program. I don't see what's unsafe about that. We're just now implying that anything can return an error instead of restating that fact every time, and instead you have to be explicit about catching it. About the functional programming... you're saying there's no if-else or early return in functional programming, but Erlang, a functional programming language, has if-else and exceptions ("throwables") that look like Java: https://learnyousomeerlang.com/errors-and-exceptions https://learnyousomeerlang.com/errors-and-exceptions. Under the hood it's one logical chain like you said, but we're using a lot of syntactic sugar on top. > if you only wanna do something in the happy case, you send in what to do using map, and then keep passing it around That's the kind of if-else early-return I mean, and it's probably what you want to do if you aren't using exceptions. My C++ code also (explicitly) passes the error around, albeit not in the functional way. In like 99% of the cases you are just passing the error up.