On Fri, Oct 7, 2016 at 8:08 PM, Dave Ford <[email protected]> wrote: > > But exception bubbling is a *feature*. An extremely useful feature. > Language level support for exceptions has been a staple of every > programming language since C. I do not consider Maybe and Result to be a > useful substitute for language level exception support. I could do Maybe > and Result in C. >
In most languages, exceptions happen when you try to *do something* deep within a tree of function calls. This maybe has to to with the side-effect nature of how things are handled almost everywhere. So, for example, I could try to read a file in python and get some file missing exception. Then it would be helpful to have that trace. However, in Elm, things are different. Elm is both purely functional AND declarative. You can imagine Elm as being an imperative shell around a functional core. The Elm program is the functional core, the runtime is the imperative shell. All possible exceptions happen outside of this core. There is nothing really to bubble up. All the code that can blow up is in the shell. All the code that interacts with the code that can blow up, is very close to the shell (at the level where you would have the generic handler). Inside the Elm code, is predictable code. Like, you want the first element of a list? What if the list is empty? You need to handle that case! If you think that this will never happen, than maybe the list is not the data structure that models your scenario, maybe you need something like a non-empty list <http://package.elm-lang.org/packages/mgold/elm-nonempty-list/latest>. If empty lists are possible and you have a default value for the cases when the list is empty, you use Maybe.withDefault defaultValue <| List.head someList. If you can come up with a practical scenario where you would have an exception, I or someone else around here could tell you what would happen in Elm in that context. Finally, you do have the option of crashing the entire program with Debug.crash and you can have a top level handler around Elm that would do what you think it is best to do in these cases. Here is a minimal alteration of the buttons example to demo this (you can paste it in elm-lang.org/try ) import Html exposing (div, button, text) import Html.App exposing (beginnerProgram) import Html.Events exposing (onClick) main = beginnerProgram { model = 0, view = view, update = update } view model = div [] [ button [ onClick Decrement ] [ text "-" ] , div [] [ text (toString model) ] , button [ onClick Increment ] [ text "+" ] , div [][ button [ onClick Crash ] [text "Crash"]] ] type Msg = Increment | Decrement | Crash update msg model = case msg of Increment -> model + 1 Decrement -> model - 1 Crash -> Debug.crash "BANG!" -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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.
