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]> wrote: > > On Thu, Oct 6, 2016 at 8:13 PM, Dave Ford <[email protected]> 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]. > 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.
