Una de las garantías de Elm es que no se observarán errores de ejecución en la práctica. Esto se debe, en parte, a que Elm trata los errores como datos. En lugar de bloquearse, modelamos explícitamente la posibilidad de fallo con tipos personalizados. Por ejemplo, supongamos que desea convertir la entrada del usuario en una edad. Podría crear un tipo personalizado como este:
type MaybeAge
= Age Int
| InvalidInput
toAge : String -> MaybeAge
toAge userInput =
...
-- toAge "24" == Age 24
-- toAge "99" == Age 99
-- toAge "ZZ" == InvalidInput
Independientemente de la entrada que se proporcione a la función toAge, siempre produce un valor. Una entrada válida produce valores como Age 24 y Age 99, mientras que una entrada no válida produce el valor InvalidInput. A partir de ahí, utilizamos la coincidencia de patrones para garantizar que se consideren ambas posibilidades. ¡Sin bloqueos!
¡Este tipo de problemas surgen constantemente! Por ejemplo, quizás quieras convertir un conjunto de entradas de usuario en una publicación para compartir. Pero, ¿qué ocurre si olvidan añadir un título? ¿O si la publicación no tiene contenido? Podríamos modelar todos estos problemas explícitamente:
type MaybePost
= Post { title : String, content : String }
| NoTitle
| NoContent
toPost : String -> String -> MaybePost
toPost title content =
...
-- toPost "hi" "¿qué tal?" == Post { title = "hi", content = "¿qué tal?" }
-- toPost "" "" == NoTitle
-- toPost "hi" "" == NoContent
En lugar de simplemente indicar que la entrada no es válida, describimos cada una de las posibles causas del error. Si tenemos una función viewPreview : MaybePost -> Html msg para previsualizar publicaciones válidas, ahora podemos mostrar mensajes de error más específicos en el área de vista previa cuando algo falla.
Este tipo de situaciones son extremadamente comunes. Suele ser útil crear un tipo personalizado para cada situación, pero en algunos casos más sencillos, puede usar un tipo estándar.
