Putting on my Erlang Developer hat (Moto: Let it Crash) I look at it this way there are two kinds .of errors, normal errors an exceptional errors. Lets say you want to go to the store to buy a dozen eggs. There are a few possible outcomes here
1) You get the eggs 2) You can't buy the eggs (Store is out of stock/ no money etc) 3) You can't get to the store because of some kind of Force Major. (IE The store burned down, the police have blocked the street due to an abandoned bag etc) The elm type system with a Maybe / Result will handle cases #1 and #2. As for case 3, that is a little harder but can still be handled. Or to take your examples - Invalid function args - Malformed JSON - Server down The first one will be handled by the type system. If you try to pass an invalid argument to a function the code will not compile. Obviously there are ways to take run time data and test for validity. You can imagine a function like "parseRomanNumeral : String -> Maybe Int" which takes a string and attempts to treat it as a roman numeral. But the Maybe is there for the case where its not. As for the Malformed JSON then you have enforced error handling code. In the case of a server down. (As Joe Armstrong said "The best type system will not prevent your server from being struck by lightning" ). Then you get a timeout error which you can handle in some useful way ᐧ On Sat, Oct 8, 2016 at 5:03 PM, Martin Janiczek <[email protected]> wrote: > Dave, how do you think about JavaScript Promises? Where you code for the > happy path (the chain of Promise.resolve().then().then().then()), any of > which can throw, and have a .catch() handler that catches whatever the > thrown value was and does something about it. > The Elm Result type is very similar to this. > > Promise.resolve(myValue) ~= Ok myValue > Promise.reject(myErrorData) ~= Err myErrorData > promise.then(fn) ~= myResult.andThen(fn) or myResult.map(fn) > promise.catch(fn) ~= case myResult of Err x -> fn x > > > Again, a specific example would help. Elm programs are not written the way > C, C#, Java programs are written. Clojure is closer but because of Java > interop reasons hasn't adopted much of the Maybe / Result / ... goodness > and instead has nils like Java has. In Elm the erorrs are explicit (like > you say, part of the return type). Read: http://blog.jenkster. > com/2016/06/how-elm-slays-a-ui-antipattern.html for how Elm solves the > Server Down error you mentioned. > > Malformed JSON is also reported not with exceptions but with Result. > Either you get your value in Ok, or helpful error message in Err. You have > to handle both cases, it doesn't propagate up, it doesn't throw a runtime > exception, the user sees what you decided to show him in that scenario. > Essentially the Elm compiler tells you "This could blow up - you told me > what to do if the JSON is OK, but what if it is not?" > > On Friday, October 7, 2016 at 10:05:50 PM UTC+2, Dave Ford wrote: >> >> >> >> On Fri, Oct 7, 2016 at 11:33 AM, Kasey Speakman <[email protected]> >> wrote: >>> >>> Then at the edge of the application, I can deal with the errors >>> >> Yes. This is what I am trying to figure out. How to deal with that class >> of errors at the "edge". >> >> Thanks. >> >> -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Zach Kessin SquareTarget <http://squaretarget.rocks?utm_source=email-sig> Twitter: @zkessin <https://twitter.com/zkessin> Skype: zachkessin -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
