Elm has datatypes called Maybe, Result and Task. You mentioned Maybe already, which may be understood to mean a list of at most one item, or a data type with either missing data, or an unspecified error. Result allows you to specify the error and propagate it, so take a look at that. Then look at Task also.
http://package.elm-lang.org/packages/elm-lang/core/4.0.5/Result On Thursday, October 6, 2016 at 11:33:43 PM UTC-4, Dave Ford wrote: > > Duane. Don't get me wrong. I prefer compile errors over runtime errors. > And if Elm can catch more errors at compile time without adding a bunch of > noise to my code that is a good thing obviously. > > But runtime errors are unavoidable. It's not possible for the compiler to > catch every possible error condition. The question is, does the language > have an elegant mechanism to deal with runtime exceptions? Especially in a > separate flow from the normal return value. > > And from what I am hearing the answer is either no or no one is telling me > what it is. > > So my question is: does Elm have something similar to throw/raise? > > On Oct 6, 2016 8:07 PM, "Duane Johnson" <[email protected] <javascript:>> > wrote: > >> >> On Thu, Oct 6, 2016 at 8:13 PM, Dave Ford <[email protected] >> <javascript:>> wrote: >> >>> 2. *Runtime Exception. *Like a NullPointerException or an >>> IllegalArgumentException. I *love* these kind of bugs. Super easy to >>> find. Super easy to fix. A stack trace tells me exactly where to look. >>> These kind of exceptions have never been a thorn in my spine. >> >> >> I'm genuinely surprised by your experience / reaction to runtime >> exceptions. My experience has been the exact opposite. Runtime exceptions >> can only be found through tedious exercise of every branch of code through >> all possible states, which creates a horrible burden on the developer who >> wishes to not have to worry about how old code might break as new code is >> added and the size of the project (and possible states) increases. >> >> When you say you love these kind of bugs, are you saying you like to go >> through your program and try this or that input and see if you can get it >> to throw an exception? What if you change the code somewhere else, but in a >> section of code that *might* affect other parts of your codebase--do you >> then go back to each of the other parts of your program and try to think of >> new ways that exceptions might have be able to be raised? >> >> I wrote part of a large (very large--possibly the largest open source >> Ruby app, called Canvas) and at some point, the complexity becomes >> mindboggling. It slows down project development when you can't check (at >> compile-time) whether a change here affects the code *there* (and *there*, >> and *there*, and, does it affect *this* code?) The motivation of Elm, as I >> see it, is to push as many classes of errors as possible into the >> compile-time error space. Not all can be pushed into that domain, but many >> can--and that's considered an advantage because as project size increases, >> you can still move with confidence. >> >> Possibly related--I found it instructive to listen to Richard's "Making >> Impossible States Impossible" presentation at ElmConf. >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Elm Discuss" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/elm-discuss/00CgYDiMvBI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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.
