Excepciones vs Valores de Error: Cómo Elegir una Estrategia

Abre un archivo que no existe en Python y open() lanza un FileNotFoundError que sube por la pila de llamadas hasta salir de tu función. Haz lo mismo en Go y os.ReadFile te devuelve un valor error junto a un slice de bytes nil. El mismo fallo, dos formas de código completamente distintas a su alrededor. La diferencia no es cosmética: decide si quien llama puede ignorar el fallo por accidente, y si el compilador se da cuenta cuando lo hace.

¿Qué hacen realmente distinto las excepciones y los valores de error?

Una excepción es control de flujo que salta. Algo falla, la función lanza, y la ejecución abandona la pila de llamadas actual para aterrizar en el primer bloque catch o except que coincida, sin importar cuántos niveles más arriba esté. La firma de la función no da ninguna pista de que esto pueda pasar. loadConfig(path: string): Config en TypeScript parece exactamente una función que no puede fallar, hasta que lanza una excepción por un archivo que falta.

Un valor de error es un dato. La función lo devuelve junto al resultado que se le pidió, o en su lugar. El (Config, error) de Go, el Result<Config, ConfigError> de Rust, y una búsqueda que devuelve null cuando no encuentra nada son la misma idea: el fallo forma parte del tipo de retorno, así que quien llama lo ve directamente en el punto de la llamada. En Rust el sistema de tipos te obliga a tratarlo antes de tocar el resultado. En Go lo hace la convención.

Ninguno de los dos enfoques es nuevo, y ninguno ha ganado. C devolvía valores centinela como -1 y NULL; las excepciones llegaron después, para sacar el manejo de errores de la lógica principal. Python, Java, C# y JavaScript usan excepciones por defecto. Go y Rust usan valores de error por defecto. La mayoría de los lenguajes que adoptan un enfoque por defecto te deja recurrir al otro cuando encaja mejor.

¿Cómo devuelve Go los errores como valores?

Go no tiene excepciones para fallos ordinarios. Una función que puede fallar devuelve un error como último valor, y quien la llama lo comprueba de inmediato:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

package main

import (
	"encoding/json"
	"fmt"
	"os"
)

type Config struct {
	Port int `json:"port"`
}

func loadConfig(path string) (Config, error) {
	data, err := os.ReadFile(path)
	if err != nil {
		return Config{}, fmt.Errorf("reading config: %w", err)
	}

	var cfg Config
	if err := json.Unmarshal(data, &cfg); err != nil {
		return Config{}, fmt.Errorf("parsing config: %w", err)
	}

	return cfg, nil
}

func main() {
	cfg, err := loadConfig("app.json")
	if err != nil {
		fmt.Fprintln(os.Stderr, "startup failed:", err)
		os.Exit(1)
	}
	fmt.Println("listening on port", cfg.Port)
}

%w envuelve el error original en lugar de descartarlo, así errors.Is y errors.As más arriba en la pila pueden comprobar qué salió mal sin comparar cadenas de texto en el mensaje.

El punto débil: nada te impide escribir data, _ := os.ReadFile(path) y descartar el error. El compilador lo acepta sin problema. Un linter como errcheck detecta los errores sin comprobar, pero solo si está configurado en tu CI.

¿Cómo saltan las excepciones de Python a un manejador?

El mismo cargador de configuración en Python no tiene comprobaciones de error en línea después de cada llamada. La comprobación ocurre alrededor de la llamada, no dentro de ella:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import json

class ConfigError(Exception):
    pass

def load_config(path):
    try:
        with open(path) as f:
            data = json.load(f)
    except FileNotFoundError as e:
        raise ConfigError(f"config file not found: {path}") from e
    except json.JSONDecodeError as e:
        raise ConfigError(f"invalid JSON in {path}: {e}") from e

    if "port" not in data:
        raise ConfigError(f"missing 'port' key in {path}")

    return data


try:
    config = load_config("app.json")
except ConfigError as e:
    print(f"startup failed: {e}")
    raise SystemExit(1)

print("listening on port", config["port"])

raise ... from e mantiene el traceback original enlazado al nuevo ConfigError, igual que %w en Go mantiene accesible el error original.

La diferencia que importa es la firma. load_config nunca dice que puede lanzar una excepción. Quien la llama tres niveles más arriba, si olvidó el try, lo descubre cuando el programa se cae con un traceback en producción, porque nada en el lenguaje comprueba el punto de la llamada.

¿Cómo obliga Result de Rust a manejar el error?

Rust mantiene la idea del error como valor y añade un sistema de tipos que no te deja tocar el valor de éxito sin reconocer el caso de fallo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

use std::fs;

#[derive(Debug)]
enum ConfigError {
    Io(std::io::Error),
    Parse(serde_json::Error),
}

#[derive(serde::Deserialize)]
struct Config {
    port: u16,
}

fn load_config(path: &str) -> Result<Config, ConfigError> {
    let data = fs::read_to_string(path).map_err(ConfigError::Io)?;
    let config: Config = serde_json::from_str(&data).map_err(ConfigError::Parse)?;
    Ok(config)
}

fn main() {
    match load_config("app.json") {
        Ok(config) => println!("listening on port {}", config.port),
        Err(e) => {
            eprintln!("startup failed: {:?}", e);
            std::process::exit(1);
        }
    }
}

Esto necesita serde (con la feature derive) y serde_json en el Cargo.toml.

Result<T, E> es un enum con dos variantes, Ok(T) y Err(E), y no puedes sacar una Config sin manejar ambas. El operador ? es un atajo para ese match: si fs::read_to_string devuelve Err, load_config retorna de inmediato con ese error, mapeado a ConfigError::Io. Si no, desempaqueta el Ok y sigue.

Aún puedes saltarte todo esto con .unwrap(), que entra en panic con Err. Es la versión de Rust de una excepción sin capturar. Trátalo como algo que cuestionar en una revisión de código, no como un atajo.

¿Por qué fetch() no lanza una excepción en un 404?

Esta división no respeta las fronteras entre lenguajes: una misma API puede mezclar ambos modelos para fallos distintos. fetch() rechaza su promise ante un fallo de red (el DNS no resuelve, la conexión se rechaza) pero se resuelve con normalidad ante un 404 o un 500. El estado HTTP es un valor en la respuesta que ya tienes: compruebas response.ok, no capturas nada. Manejo de Errores con la Fetch API en JavaScript explica por qué esto sorprende a quien espera que un error HTTP lance una excepción, y cómo envolver fetch() para recuperar un comportamiento al estilo excepción si lo quieres.

¿Cuándo usar excepciones, y cuándo devolver errores?

Hazte una pregunta sobre el fallo concreto: ¿quien llama de inmediato tiene que actuar sobre él, o debería viajar hacia arriba hasta que algún límite lo gestione?

Un cache miss o un error de validación en la entrada del usuario es un resultado que tu código debería esperar y sobre el que ramificar ahí mismo. Un valor de error encaja. Quien llama no puede hacer su trabajo sin reaccionar, así que un tipo de retorno que hace visible el fallo es una ayuda, no ceremonia.

Una conexión a base de datos que se cae a mitad de una transacción, o una aserción sobre el estado del programa que resulta ser falsa, son distintas. Nada de lo que haga quien llama de inmediato lo va a arreglar. Dejar que se propague como excepción o panic hasta un único lugar que lo registre y cierre limpiamente es menos código, y código más honesto, que hacerlo atravesar manualmente cada frame.

Los lenguajes que adoptan un modelo por defecto ya usan el otro donde encaja. Go entra en panic ante un índice de slice fuera de rango, porque eso es un bug, no una condición que quien llama deba manejar. Rust entra en panic ante un desbordamiento de enteros en builds de debug. El dict.get(key, default) de Python devuelve un valor en lugar de lanzar KeyError, para el caso en que una clave ausente se espera en vez de ser excepcional.

¿Qué sale mal con cada estrategia en la práctica?

Errores tragados. Un except: vacío que no hace nada, o un if err != nil { } en Go con el cuerpo vacío, borra el fallo. El síntoma aparece más tarde como datos faltantes o una pantalla en blanco, sin ningún error cerca de la causa real. Es el flujo difícil de rastrear descrito en Qué Es el Spaghetti Code y Cómo Refactorizarlo.

Panics en la goroutine equivocada. recover() solo funciona dentro de la goroutine que entró en panic. Un recover diferido en main no te salva de un panic en una goroutine worker; todo el programa se cae. Goroutines y Channels en Go: Guía con Ejemplos muestra por qué los errores del trabajo concurrente deberían volver por un channel, como valores.

.unwrap() y un catch genérico en lugar de una decisión. Ambos te permiten dejar de pensar en el caso de fallo sin hacerlo desaparecer de verdad. Escribe una prueba que fuerce el camino de error. Es mucho más fácil cuando la función devuelve un error que puedes construir tú mismo que cuando lo lanza desde dentro de una librería que no controlas, y es la razón por la que los caminos de error tienen pruebas propias en Pruebas Unitarias vs de Integración vs End-to-End.

¿Cómo elegir entre excepción y valor de error, función por función?

La próxima vez que estés por escribir throw o return err, mira la función que tienes delante. Si quien la llama debe reaccionar de inmediato, pon el fallo en el tipo de retorno: (T, error) en Go, Result en Rust, None o un default en Python. Si no puede pasar nada útil hasta que el fallo llegue a un manejador de nivel superior, lanza una excepción o un panic y manéjalo una sola vez, en ese límite. Luego añade una prueba para el camino de error, cualquiera que hayas elegido.

Artículos relacionados

• Manejo de Errores con la Fetch API en JavaScript
• Qué Es el Spaghetti Code y Cómo Refactorizarlo
• Goroutines y Channels en Go: Guía con Ejemplos
• Pruebas Unitarias vs de Integración vs End-to-End