El módulo File en Elixir nos abre la puerta para trabajar con archivos de manera directa, permitiéndonos abrir, leer, escribir, borrar, copiar y crear directorios. Sin embargo, estas operaciones no son funciones puras en el sentido estricto de la programación funcional, porque pueden fallar dependiendo del estado del sistema de archivos o del entorno en el que se ejecuten.
En la programación funcional, estamos acostumbrados a que las funciones sean puras: para las mismas entradas, siempre obtenemos las mismas salidas. Por ejemplo, si llamamos muchas veces a 3 + 4, siempre obtendremos 7. Lo mismo ocurre con funciones como String.upcase("hola"), que siempre devolverá "HOLA". Pero cuando interactuamos con el mundo real, como leer archivos o acceder a recursos externos, esta pureza se rompe. Un archivo puede existir o no, una conexión a internet puede fallar, y por tanto, nuestras funciones pueden devolver resultados diferentes o incluso errores.
Para ilustrar esto, podemos usar la función File.exists?, que nos devuelve true si el archivo existe y false si no. Por ejemplo, si tenemos un archivo llamado existo.txt con contenido, File.exists?("existo.txt") devolverá true. Pero si consultamos por un archivo inexistente, devolverá false. Aunque esta función devuelve un booleano, no es pura porque su resultado depende del estado externo del sistema de archivos.
Cuando queremos leer un archivo, la función File.read es especialmente interesante porque no devuelve simplemente el contenido o un error, sino que devuelve una tupla con dos elementos. El primer elemento es un átomo que indica si la operación fue exitosa (:ok) o si hubo un error (:error). El segundo elemento es el contenido del archivo en caso de éxito, o un átomo que describe el error en caso contrario, como :enoent para indicar que el archivo no existe.
Esto nos permite usar pattern matching para manejar ambos casos de forma clara. Por ejemplo, si hacemos:
{:ok, contenido} = File.read("existo.txt")
estamos diciendo que esperamos que la función devuelva una tupla cuyo primer elemento sea :ok y cuyo segundo elemento lo asignamos a la variable contenido. Si el archivo no existe y la función devuelve {:error, :enoent}, este pattern matching fallará y se lanzará un MatchError.
Por eso, antes de hacer un pattern matching directo con :ok, es recomendable comprobar que el archivo existe con File.exists?. De lo contrario, podemos manejar la respuesta con un condicional o un case para tratar ambos escenarios:
case File.read("existo.txt") do
{:ok, contenido} ->
IO.puts("Contenido del archivo: #{contenido}")
{:error, :enoent} ->
IO.puts("El archivo no existe")
{:error, otro_error} ->
IO.puts("Error al leer el archivo: #{otro_error}")
end
Este enfoque nos permite capturar los posibles errores y actuar en consecuencia, evitando que el programa falle inesperadamente.
Además, es importante entender cuándo puede fallar un pattern matching. Por ejemplo, si intentamos hacer:
{:ok, texto} = File.read("archivo_inexistente.txt")
y la función devuelve {:error, :enoent}, el pattern matching no se cumplirá porque :ok no coincide con :error, y se lanzará un error. Esto sucede porque estamos usando una constante (:ok) a la izquierda que no coincide con el valor real a la derecha.
En resumen, al trabajar con funciones impuras como las del módulo File, debemos estar preparados para manejar tanto los casos de éxito como los de error. El pattern matching es una herramienta poderosa para esto, pero requiere que sepamos cuándo usarlo directamente y cuándo manejar los posibles fallos con estructuras de control como case. Así, podemos escribir código más robusto y claro al interactuar con el sistema de archivos en Elixir.