3 ms·

I used to think so, but * Java also has unchecked exceptions, and, incredibly, there's still no consensus as to which exceptions should be used for what and wh

by bedobi 7y ago

I used to think so, but * Java also has unchecked exceptions, and, incredibly, there's still no consensus as to which exceptions should be used for what and when, though these days the most common approach is to simply stick only to RuntimeExceptions, which is terrible. * Functional error handling using Option, Either, Try etc are arguably much simpler, safer and more powerful than exceptions. Simpler because they don't rely on dedicated syntax- they're just regular objects no different to any other object. Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. (no risk of ignoring errors and no risk of catching a higher level of error than desired, ubiquitous bugs in exception based error handling) Powerful because they support map, flatmap, applicative etc, making it easy to eg chain multiple computations together in desired ways, which is unwieldy and bug prone when using exceptions. It could be that, when learning Java, Python and any other language, we learn that methods return objects... and that's that. No weird dedicated syntax and magic, special treatment for returning anything other than the happy path, and the HUGE complexity that comes with it, eg the dedicated syntax itself and how it behaves, differences between checked and unchecked exceptions, hierarchies of exceptions etc etc. When lists and booleans also implement map, flatMap etc, you can actually reduce syntax of languages even further- there's no need for looping syntax like for, while etc, and no need for if else either. This is probably too extreme for most people, but think about it!

dkersten 7y ago
Slightly off topic, but what should a map or flatMap implementation on boolean do? Presumably run on true and skip on false? That’s not really what I expect from map (that it’s filtered the input). I could imagine book.filter.map as a way to conditionally execute
- bedobi 7y ago
  Haha you're putting me on the spot here, I guess I haven't really thought too deeply about the specifics! Maybe flatMap would return true only if all chained booleans are true? Bimap would allow you to provide functions for what to do in true and false case? Fold would allow you to turn true or false into a single type? I'm sure someone more experienced in FP can weigh in with something more correct! :p
- karmakaze 7y ago
  I rather like that, `if condition` is a 0/1 iteration with no input. flatMap can return empty, what should map return when run on false, None?
  - mrgriffin 7y ago
    I'd probably think of Bool as being isomorphic to Maybe (), which would mean your map implementation looks a bit like: map :: Bool -> (() -> b) -> Maybe b map True f = Just (f ()) map False _ = Nothing Or, in Haskell because you've got laziness you could go with: map :: Bool -> b -> Maybe b Which already exists as a combination of Control.Monad.guard and Data.Functor.(<$). map tf b = b <$ guard tf
quelltext 7y ago
Checked exceptions really aren't much different from dedicated return type for errors. The Either type in Haskell and its Monad is really not doing anything fundamentally different: Bubbling up errors until the point where someone cares/needs to handle them (though I have to say I hate the whole Left / Right convention thing, just define a dedicated type with proper constructors for value vs. error already). In fact I'd say checked exceptions are a richer formalism since they essentially provide something akin to intersection types for errors. The fact that there are also RuntimeExceptions comes up a lot as an argument against Java/checked exceptions but that doesn't convince me. Haskell also has runtime errors that can happen (division by 0) that are outside the Either or Option/Maybe world. The problem is maybe rather that people are lazy and the trend became to decide that everything should be a RuntimeException because who needs all that noise and checked exception handling, right? I'm fairly certain that people who rejected checked exceptions would also reject the more functional approaches. My argument is that no consensus around using checked exceptions correctly ever developed and so they never really had a chance to shine. Having said that, sure I think having more usage of idioms we find in FP for error handling/propagation or early aborting is great. It's better than just raising runtime exceptions. However we are still in a world where no widely known language actually enforces (!) error handling in that fashion. It's all convention in the end. And so my point was that if you want a language that tries to encourage error handling, with known failure modes communicates in the method signature then Java's checked exceptions sound pretty close. Sure they are not perfect but the question is whether it's worth exploring better formalisms along the lines of first class errors with dedicates language support or piggybacking on the existing type system features and introduce conventions? The latter sort if works but I find it less ...exciting.

by bedobi 7y ago

dkersten 7y ago

Slightly off topic, but what should a map or flatMap implementation on boolean do? Presumably run on true and skip on false? That’s not really what I expect from map (that it’s filtered the input). I could imagine book.filter.map as a way to conditionally execute

bedobi 7y ago
Haha you're putting me on the spot here, I guess I haven't really thought too deeply about the specifics! Maybe flatMap would return true only if all chained booleans are true? Bimap would allow you to provide functions for what to do in true and false case? Fold would allow you to turn true or false into a single type? I'm sure someone more experienced in FP can weigh in with something more correct! :p
karmakaze 7y ago
I rather like that, `if condition` is a 0/1 iteration with no input. flatMap can return empty, what should map return when run on false, None?
- mrgriffin 7y ago
  I'd probably think of Bool as being isomorphic to Maybe (), which would mean your map implementation looks a bit like: map :: Bool -> (() -> b) -> Maybe b map True f = Just (f ()) map False _ = Nothing Or, in Haskell because you've got laziness you could go with: map :: Bool -> b -> Maybe b Which already exists as a combination of Control.Monad.guard and Data.Functor.(<$). map tf b = b <$ guard tf

quelltext 7y ago

Checked exceptions really aren't much different from dedicated return type for errors. The Either type in Haskell and its Monad is really not doing anything fundamentally different: Bubbling up errors until the point where someone cares/needs to handle them (though I have to say I hate the whole Left / Right convention thing, just define a dedicated type with proper constructors for value vs. error already). In fact I'd say checked exceptions are a richer formalism since they essentially provide something akin to intersection types for errors. The fact that there are also RuntimeExceptions comes up a lot as an argument against Java/checked exceptions but that doesn't convince me. Haskell also has runtime errors that can happen (division by 0) that are outside the Either or Option/Maybe world. The problem is maybe rather that people are lazy and the trend became to decide that everything should be a RuntimeException because who needs all that noise and checked exception handling, right? I'm fairly certain that people who rejected checked exceptions would also reject the more functional approaches. My argument is that no consensus around using checked exceptions correctly ever developed and so they never really had a chance to shine. Having said that, sure I think having more usage of idioms we find in FP for error handling/propagation or early aborting is great. It's better than just raising runtime exceptions. However we are still in a world where no widely known language actually enforces (!) error handling in that fashion. It's all convention in the end. And so my point was that if you want a language that tries to encourage error handling, with known failure modes communicates in the method signature then Java's checked exceptions sound pretty close. Sure they are not perfect but the question is whether it's worth exploring better formalisms along the lines of first class errors with dedicates language support or piggybacking on the existing type system features and introduce conventions? The latter sort if works but I find it less ...exciting.