What to do if you have a Non Exhaustive pattern match

Learn
5

“No runtime errors” is a very high priority for Elm. This means that you are not allowed to create functions that can fail. (Unless you’re implementing a core function like modBy 0.) The unsatisfying the solution of choosing a default value is probably your best choice. What I would do is:

  1. Use Debug.todo in your code while developing to mark the impossible branches.
  2. Write exhaustive tests and make sure you never run into those errors.
  3. Replace Debug.todo by a default value.

(You might consider writing a custom wrapper around Debug.todo that already takes a value of the correct type so that you only need to change the definition of your custom wrapper before finalizing the module instead of replacing every occurrence of Debug.todo.)

Unfortunately, there are still two problems:

  1. Having to use different code for development and production builds is annoying.
  2. If you are tasked with producing a value of an unknown type (say you have a function MyTree a -> a and you know that the tree will always contain a value to return but you can’t prove it to the compiler), you’re out of luck and your “infinite recursion” solution is basically your only choice.