And How it Contrasts with Javascript In there are a handful of ways to deal with situations that don’t follow the happy path. Javascript You could by protectively checking values and . be disciplined return safe responses You could as much as possible. be exhaustively disciplined by doing TDD You could use to mimic languages that have checked exceptions. try-catch and throw You could and let runtime errors have a detrimental impact on user experience. do nothing When writing Elm apps you’ll inevitably run across a situation when you need to handle a non-happy path situation. Your first intuition may be to look for the strategy that you used on that one Javascript project, but that other way may not be available to you with Elm. In this post I’ll outline the types of “error” situations you can find yourself in when writing Elm applications and I’ll describe how Elm makes handling these situations pleasant and safe. Unexpected Types The first type of error that you’ll find in Javascript is a . It’s the notorious or . type error undefined is not a function cannot read property “something” of undefined In Elm applications, you will . Elm is a statically typed language and it has the following protections in place. never see this error The Compiler The compiler will guarantee that if you declare a constant as a String, for example, that constant could only ever be treated as a String. It can’t be an Int. It can’t be null. It can’t be undefined. If you attempt to make it anything other than a String the application . will not compile Immutable Constants Elm doesn’t have variables that can be reassigned to different values or types. Elm has , or perhaps better thought of as . As such, your declarations can’t change types out from under you. immutable constants zero argument pure functions Maybes Many languages treat null and undefined as subtypes. This is the infamous . In Elm the equivalent of null is called , and it is one of the tag names in a tagged union called a . billion dollar mistake Nothing Maybe Elm treats nullability as a separate type Said differently, Elm treats . As a result, the concept of must be handled explicitly as part of the type system, thus preventing many common runtime errors. nullability as a separate type null Unexpected Data Applications receiving input from the outside world will inevitably receive data in a . In Elm there are a couple of entry points where data from the outside world can be received. shape or type that it wasn’t expecting Messages from Html.Event handlers Messages dispatched from Html.Event have and are therefore guaranteed to supply the Elm app with a Message and a payload of the correct type. This is yet another example of the type system guaranteeing that you’re going to handle the right type of value without you doing any additional work. specific types Messages from Tasks Tasks are how you perform most side-effects, such as performing Http requests. One of the arguments that must be provided for performing an is a Decoder. A is a composable type that Elm uses to transform JSON into a type that you can work with. Elm accomplishes this by handing you a which is a specialized that will either hold an error (a failure to transform the JSON) or a success value (the transformed value). Http request Decoder Result either type Elm hands you a specialized either type, called a Result If there is an error then the compiler will force you to handle that error. This is your opportunity to update the application state with an indication that unexpected data was received. Async Failures When making HTTP requests those requests can ultimately fail for a variety of reasons. With Javascript you’ll pass a to handle successful responses and there’s an to handle failures. success callback optional failure callback Elm is different. Rather than exposing an optional failure callback you’ll instead be asked to provide that accepts a Result (the same specialized either type discussed above) as input and that callback returns a Message that will likely be different depending on the Result. a callback What this means is async errors have to be explicitly handled, as opposed to being . accidentally forgotten Preventing errors with carefully designed data structures By far, my favorite type of error to handle is . If a bad situation can occur, and you can reasonably prevent it, why not prevent it? absolutely no error at all The way to accomplish this can best be elaborated by Richard Feldman’s talk but my current two favorite examples that apply this idea are Kris Jenkins’ package and Max Goldstein’s package. Make Impossible States Impossible RemoteData elm-nonempty-list Here’s a demonstration of using RemoteData. RemoteData Example In using this package we’re preventing a certain “error scenario” where the view could be out of sync with what is actually happening during a request. Because RemoteData is a in the Model, the compiler will force you to handle the four different Tags that the RemoteData can be, thus forcing you to explicitly handle in the view layer the different parts of the asynchronous request’s lifecycle. type Caveats I lied in the section above. There are actually two more ways that an Elm application can receive data from the outside world. Unexpected Data On app initialization with Html.programWithFlags When receiving Messages from ports In my opinion, the current version of Elm (0.18) doesn’t handle these situations so well when it comes to . When using programWithFlags it’s possible to have a when the application is initialized with a value that it’s not expecting. When using a port subscription it’s possible to have a yet again when an unexpected value is sent to the Elm application. error handling runtime exception runtime exception (open the console to see the errors) I asked about both of these specifically and I got indicated that ports and programWithFlags predated Decoders, and that we shouldn’t expect that decision to change in the near future, which is fine. the response design There was also a helpful suggestion to use . In other words, declaring the data as a JSON value will force you to use a Decoder to turn the JSON value into a type that your Elm application can use. Json.Decode.Value So the best answer I have to these two situations is to and use when using programWithFlags and port subscriptions. It’s a pattern that’s consistent with explicitly handling errors and preventing runtime exceptions. be disciplined Json.Decode.Value Concluding Remarks I find handling error situations in Elm to be a rather pleasant experience. Elm will force you to handle errors essentially by leveraging the type system which is great both in its simplicity and the resulting developer experience. I suppose one of the bigger takeaways from this post is if you happen to be working on a Javascript application you can employ these same strategies by adding a implementation that also has the equivalent of . I realize it’s easy to say and harder to do. But for me at least it’s good to know that I can leverage some of the benefits that I get with Elm by introducing static types to the Javascript applications that I work on. static type tagged unions is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising &sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
![Comparing the Best TypeScript Alternatives [Part I]](https://hackernoon.imgix.net/images/XIlys8PrM8eJ7n0qjETjuC0lbkB2-dze3qzq.jpeg?auto=format&fit=max&w=3840)
