Errores como valores: la filosofía de Go

En Go, un error no es una interrupción catastrófica que salta fuera del flujo normal de ejecución; es simplemente un valor más que una función devuelve. Mientras que en otros lenguajes usas try/catch para capturar excepciones que “vuelan” a través de la pila de llamadas, en Go el error es una interfaz error que se trata como cualquier otro dato. Esta decisión de diseño, impulsada por la filosofía de “errors are values”, significa que el fallo es una parte predecible y explícita del flujo de control.

Cuando diseñas una función que puede fallar, el contrato es claro: devuelves el resultado esperado y, junto a él, un objeto de error. Esto hace que los fallos sean visibles en la firma de la función, obligándote a decidir qué hacer en el punto exacto donde ocurre el problema. Es ideal para manejar condiciones expected (como un archivo que no existe o una respuesta de red lenta), ya que tratas el error como parte de la lógica de negocio y no como algo “excepcional”. Sin embargo, si ignoras estos valores (usando el identificador en blanco _), rompes la seguridad del flujo, ya que estarás operando con el “zero value” del tipo de retorno (como un nil, un 0 o un ""), lo que suele derivar en panics o comportamientos erráticos más adelante en la ejecución.

package main

import (
	"errors"
	"fmt"
)

// Definimos errores sentinela para comparar errores específicos.
var (
	ErrConfigNotFound = errors.New("archivo de configuración no encontrado")
	ErrInvalidFormat  = errors.New("formato de configuración inválido")
)

// ConfigLoader simula la carga de una configuración.
// El retorno múltiple (map[string]string, error) es el patrón estándar en Go.
func LoadConfig(path string) (map[string]string, error) {
	if path == "" {
		// Devolvemos nil para el valor y el error correspondiente.
		return nil, ErrConfigNotFound
	}

	if path == "bad_config" {
		// Usamos fmt.Errorf con %w para envolver errores (error wrapping).
		// Esto permite que el error original sea accesible mediante errors.Is.
		return nil, fmt.Errorf("error crítico en %s: %w", path, ErrInvalidFormat)
	}

	// Escenario de éxito.
	config := map[string]string{
		"api_url": "https://api.production.com",
		"timeout": "30s",
	}
	return config, nil
}

func main() {
	// Probamos tres escenarios: error de ruta, error de formato y éxito.
	paths := []string{"config.yaml", "bad_config", ""}

	for _, p := range paths {
		fmt.Printf("--- Intentando cargar: %s ---\n", p)
		
		// El patrón 'if err != nil' es la forma estándar de manejar el flujo.
		cfg, err := LoadConfig(p)
		if err != nil {
			// Aquí el programador decide: ¿detener el programa o continuar?
			// En este caso, simplemente informamos el error y seguimos.
			if errors.Is(err, ErrInvalidFormat) {
				fmt.Printf("Error de formato detectado: %v\n", err)
			} else {
				fmt.Printf("Error inesperado: %v\n", err)
			}
			continue
		}

		// Si llegamos aquí, 'cfg' es garantizadamente seguro para usar.
		fmt.Printf("Configuración cargada: %v\n", cfg)
	}
}

Desglose del código

En la función LoadConfig, observa cómo la firma (map[string]string, error) establece un contrato estricto. No hay magia: si algo sale mal, el retorno es explícito. Cuando la ruta es vacía, retornamos nil como primer valor; esto es una convención: si hay un error, el valor de retorno debe ser su valor cero para evitar que el caller intente usar basura.

En el caso de "bad_config", utilizamos fmt.Errorf con el verbo %w. Esto es crucial en Go moderno: no estamos simplemente concatenando strings, estamos “envolviendo” el error ErrInvalidFormat. Esto permite que, más arriba en la pila, podamos usar errors.Is(err, ErrInvalidFormat) para identificar la causa raíz, incluso si el mensaje de error ha sido decorado con más contexto.

En el main, el bucle for procesa cada ruta. Fíjate en la estructura de control: el if err != nil no es solo una comprobación, es el punto de decisión de tu aplicación. Si el error es de formato, lo tratamos de una forma; si es cualquier otro, de otra. Solo si el error es nil permitimos que el código continúe hacia la lógica que consume cfg. Esta estructura evita que una función de alto nivel tenga que lidiar con excepciones inesperadas; el control del flujo es lineal y fácil de seguir con la mirada.

El error frecuente

Un error muy común en desarrolladores que vienen de lenguajes con excepciones es intentar ignorar el error para “limpiar” el código, especialmente en pruebas rápidas o scripts:

// ¡PELIGRO!
cfg, _ := LoadConfig("") 
fmt.Println(cfg["api_url"]) 

Aquí, al usar _, estamos ignorando el error ErrConfigNotFound. Como LoadConfig retornó nil para el mapa, cfg es nil. Intentar acceder a una llave de un mapa nil en Go es seguro y devuelve el valor cero del tipo, pero si cfg fuera un puntero o una estructura, estarías a un paso de un panic: runtime error: invalid memory address or nil pointer dereference. El diseño de Go te obliga a ser explícito para protegerte de estos estados inconsistentes.

N° 88