Errores personalizados en Go

Contenido del curso

Introducción y Configuración

Fundamentos de Go

Estructuras de Datos y Funciones

Manejo de Errores y Concurrencia

Buenas Prácticas en Go

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:008:25

Errores personalizados en Go

Curso de Go

Clase 20 de 28

Clase 20 / 28

Recursos

Crear errores personalizados en Go te permite reemplazar mensajes confusos como stack overflow o memory exception por textos claros que tú defines. Esta práctica es clave para desarrolladores que buscan código mantenible, equipos que necesitan depurar rápido y usuarios finales que merecen mensajes entendibles.

¿Por qué conviene crear errores personalizados en Go?

Cuando una aplicación falla, el mensaje que devuelve marca la diferencia entre resolver el bug en minutos o pasar horas buscando la causa. Go te da las herramientas para que tú decidas qué leer cuando algo se rompe.

Imagina que tu cafetera falla. ¿Prefieres leer "se desbordó la memoria en el lote número 15" o "ya no hay café"? El segundo mensaje te dice exactamente qué pasó y cómo arreglarlo. Esa misma lógica aplica a cualquier sistema en producción.

¿Qué es un error personalizado en Go? Es una variable que tú declaras usando el paquete fmt o errors para definir un mensaje claro que reemplace los errores genéricos del lenguaje.

¿Cómo declarar errores personalizados con fmt.Errorf?

La receta es directa: importas los paquetes que necesitas y declaras tus errores como variables. Aquí entran en juego fmt para formatear el mensaje y errors como paquete dedicado al manejo de errores.

go package main

import ( "fmt" "errors" )

var errorDeCafe = fmt.Errorf("Ya no hay café") var errorDeEnergia = fmt.Errorf("Ya no hay electricidad")

Con estas dos variables ya tienes un catálogo de errores listos para devolver desde cualquier función. La ventaja: el mensaje viaja contigo a lo largo de toda la aplicación.

¿Qué función usar para retornar errores en Go?

Define una función que reciba un argumento y retorne un valor de tipo error. Si la condición se cumple, retornas tu error personalizado; si no, retornas nil.

go func HacerCafe(args int) error { if args == 2 { return errorDeCafe } else if args == 3 { return errorDeEnergia } return nil }

Fíjate en el detalle de sintaxis: en Go el else debe ir en la misma línea que la llave de cierre del if anterior. Si lo escribes en otra línea, el compilador marca error.

¿Cómo capturar y mostrar errores dentro de un ciclo for?

Una vez que tu función retorna errores, necesitas evaluarlos. El patrón clásico en Go es comparar el error contra nil y, si es diferente, decidir qué hacer según el tipo de error recibido.

go func main() { for i := 0; i < 5; i++ { err := HacerCafe(i) if err != nil { fmt.Println(err) } else { fmt.Println("Ya hay café") } } }

Al ejecutar go run main.go con un ciclo de 5 iteraciones, los valores 0 y 1 imprimen "Ya hay café" porque ninguna condición se cumple. En la iteración 2 aparece el mensaje "Ya no hay café" y en la 3 aparece "Ya no hay electricidad". Estás manipulando el flujo para que Go muestre exactamente lo que tú definiste.

¿Cuándo retornar nil en Go? Cuando la función no encuentra ninguna condición de error. Devolver nil indica que todo salió bien y evita falsos positivos en el manejo de errores.

¿Qué ventajas tiene usar errores personalizados frente a console.log?

Muchos desarrolladores recurren a imprimir variables por consola para rastrear bugs. En Go puedes saltarte ese paso si diseñas bien tus errores desde el inicio.

Claridad para el equipo: cualquier developer que lea el código entiende qué falló sin abrir documentación.
Mensajes para el usuario final: la persona que usa tu app recibe textos en lenguaje natural.
Depuración más rápida: identificas el punto exacto del fallo sin agregar Println temporales.
Código mantenible: tus errores viven como variables centralizadas, fáciles de actualizar.

Esta forma de trabajar le da calma a tu equipo y reduce el tiempo entre detectar un problema y resolverlo. ¿Ya tienes pensado qué errores personalizados implementarías en tu próximo proyecto en Go? Cuéntame en los comentarios cuál sería tu primer error personalizado.

package errors
func New(text string) error {
	return &errorString{text}
}
type errorString struct {
	s string
}
func (e *errorString) Error() string {
	return e.s
}
var ErrUnsupported = New("unsupported operation")

package main

import (
	"fmt"
)

// En Go, un error personalizado se crea implementando el método `Error()`
// de la interfaz `error`.

// CoffeeError representa un error específico al ordenar café
type CoffeeError struct {
	Code    int    // Un código para identificar el tipo de error
	Message string // Descripción del error
}

// El método `Error()` convierte CoffeeError en un error válido de Go
func (e CoffeeError) Error() string {
	return fmt.Sprintf("Error %d: %s", e.Code, e.Message)
}

// orderCoffee intenta preparar un café, pero puede fallar
func orderCoffee(size string) error {
	// Simulamos algunos casos de error
	if size == "" {
		return CoffeeError{Code: 400, Message: "Debes elegir un tamaño de café."}
	}
	if size == "extra-grande" {
		return CoffeeError{Code: 404, Message: "Ese tamaño de café no existe."}
	}
	if size == "expreso" {
		return CoffeeError{Code: 503, Message: "La máquina de expreso está en mantenimiento."}
	}

	// Si no hay error, todo sale bien
	fmt.Printf("☕ Preparando tu café tamaño '%s'...\n", size)
	return nil
}

func main() {
	// Intentamos ordenar varios cafés para ver los diferentes resultados
	sizes := []string{"", "extra-grande", "expreso", "mediano"}

	for _, s := range sizes {
		err := orderCoffee(s)
		if err != nil {
			// Aquí mostramos el error personalizado
			fmt.Println("❌ Ocurrió un problema:", err)
		} else {
			fmt.Println("✅ ¡Tu café está listo!")
		}
		fmt.Println("-----------------------------")
	}
}

Resumen

¿Por qué conviene crear errores personalizados en Go?

¿Qué es un error personalizado en Go? Es una variable que tú declaras usando el paquete fmt o errors para definir un mensaje claro que reemplace los errores genéricos del lenguaje.

¿Cómo declarar errores personalizados con fmt.Errorf?

go package main

import ( "fmt" "errors" )

var errorDeCafe = fmt.Errorf("Ya no hay café") var errorDeEnergia = fmt.Errorf("Ya no hay electricidad")

Con estas dos variables ya tienes un catálogo de errores listos para devolver desde cualquier función. La ventaja: el mensaje viaja contigo a lo largo de toda la aplicación.

¿Qué función usar para retornar errores en Go?

Define una función que reciba un argumento y retorne un valor de tipo error. Si la condición se cumple, retornas tu error personalizado; si no, retornas nil.

go func HacerCafe(args int) error { if args == 2 { return errorDeCafe } else if args == 3 { return errorDeEnergia } return nil }

Fíjate en el detalle de sintaxis: en Go el else debe ir en la misma línea que la llave de cierre del if anterior. Si lo escribes en otra línea, el compilador marca error.

¿Cómo capturar y mostrar errores dentro de un ciclo for?

Una vez que tu función retorna errores, necesitas evaluarlos. El patrón clásico en Go es comparar el error contra nil y, si es diferente, decidir qué hacer según el tipo de error recibido.

go func main() { for i := 0; i < 5; i++ { err := HacerCafe(i) if err != nil { fmt.Println(err) } else { fmt.Println("Ya hay café") } } }

¿Cuándo retornar nil en Go? Cuando la función no encuentra ninguna condición de error. Devolver nil indica que todo salió bien y evita falsos positivos en el manejo de errores.

¿Qué ventajas tiene usar errores personalizados frente a console.log?

Muchos desarrolladores recurren a imprimir variables por consola para rastrear bugs. En Go puedes saltarte ese paso si diseñas bien tus errores desde el inicio.

Claridad para el equipo: cualquier developer que lea el código entiende qué falló sin abrir documentación.
Mensajes para el usuario final: la persona que usa tu app recibe textos en lenguaje natural.
Depuración más rápida: identificas el punto exacto del fallo sin agregar Println temporales.
Código mantenible: tus errores viven como variables centralizadas, fáciles de actualizar.

Samuel Soto Hoyos

Hace un año

Go, como lenguaje, fomenta un enfoque distinto para el manejo de errores en comparación con otros lenguajes que utilizan excepciones o aserciones. El objetivo es hacer que el manejo de errores sea explícito, comprensible y que permita que los servidores continúen operando incluso después de errores no fatales.

A continuación, se presentan las buenas prácticas para el manejo de errores en Go:

Múltiples valores de retorno: La forma principal de informar errores es mediante el retorno de múltiples valores, donde uno de los valores es el tipo error incorporado. Si una función se ejecuta con éxito, el valor error debe ser nil. Esto permite que una función devuelva un resultado útil y una indicación de error simultáneamente.
- Ejemplo: La función Write en Go retorna el número de bytes escritos (n int) y un error.
- Siempre revise los retornos de error: Descartar los valores de error con el identificador en blanco (_) es una mala práctica y puede llevar a fallos inesperados. Los errores se proporcionan por una razón.
Interfaz error:
- La interfaz error es una interfaz simple y predefinida que requiere un solo método: Error() string.
- Las librerías pueden implementar esta interfaz con modelos más ricos, como os.PathError, que proporciona contexto adicional como la operación y la ruta del archivo que causaron el error.
- Los strings de error deben identificar su origen, por ejemplo, incluyendo un prefijo que nombre la operación o el paquete que generó el error (ej. "image: unknown format").
- Los llamadores pueden usar una declaración type switch o una aserción de tipo para inspeccionar errores específicos y extraer detalles si es necesario.
Manejo de pánicos (panic) y recuperación (recover):
- panic: Utilice panic solo para condiciones verdaderamente excepcionales e irrecuperables que impiden que el programa continúe su ejecución normal. Por ejemplo, si una librería no puede inicializarse correctamente. panic detiene inmediatamente la ejecución de la función actual y comienza a desenrollar la pila de la goroutine, ejecutando cualquier función diferida (defer) en el camino.
- Evite exponer panic a los clientes: Las funciones de las librerías deben evitar usar panic si el problema puede ser enmascarado o solucionado. Es mejor convertir los pánicos internos en valores error antes de retornar a los clientes.
- recover: La función recover solo es útil dentro de una función diferida (defer). Permite que una goroutine que está en estado de pánico recupere el control y reanude la ejecución normal. Esto es particularmente útil en servidores, donde una goroutine que falla puede ser apagada limpiamente sin afectar a otras goroutines en ejecución. Al llamar a recover, se detiene el desenrollado de la pila y se devuelve el argumento pasado a panic.
La declaración defer para la gestión de recursos:
- La declaración defer programa una llamada a una función para que se ejecute justo antes de que la función que la contiene retorne. Esto es crucial para liberar recursos de manera garantizada, como cerrar archivos o desbloquear mutexes, sin importar la ruta de retorno de la función.
- Los argumentos de una función diferida se evalúan en el momento en que se ejecuta la instrucción defer, no cuando la llamada se ejecuta realmente.
- defer es fundamental para el patrón panic/recover, ya que las funciones diferidas son las únicas que se ejecutan durante el proceso de pánico.
Consideraciones con nil en interfaces y canales:
- Una variable de interfaz que almacena un puntero nil a un tipo concreto no es nil en sí misma. Esto puede llevar a que una comparación if err != nil retorne true aunque el valor subyacente sea nil. Para retornar un nil error adecuado, la función debe devolver explícitamente nil.
- Los canales nil nunca están listos para la comunicación; cualquier operación de envío o recepción en un canal nil se bloquea indefinidamente. Cerrar un canal nil causa un pánico en tiempo de ejecución.
Finalizadores, limpiezas (cleanups) y punteros débiles (weak pointers):
- Estas características permiten observar y reaccionar a la "muerte" de un objeto (cuando ya no es alcanzable por el programa).
- Consejo general:
  - Escriba pruebas unitarias para el código que usa estas características, ya que su momento de ejecución es difícil de predecir.
  - Evite usarlas directamente en código Go típico; son características de bajo nivel con restricciones y comportamientos sutiles.
  - Encapsule su uso dentro de un paquete y proporcione interfaces que dificulten el uso incorrecto por parte de los usuarios.
  - Prefiera la limpieza determinista de recursos no relacionados con la memoria (ej. descriptores de archivo) mediante APIs explícitas (como un método Close), usando finalizadores y cleanups como un último recurso para errores de programación.
  - Prefiera cleanups a los finalizadores a partir de Go 1.24, ya que son más flexibles, menos propensos a errores y más eficientes. Los finalizadores pueden resucitar objetos y crear ciclos de referencia, impidiendo que la memoria sea liberada.
Identificación y eliminación de asignaciones en el "heap":
- Reducir la cantidad de valores que el recolector de basura (GC) debe gestionar es una forma efectiva de reducir los costos del GC.
- Utilice el perfilado de memoria (heap profiling) para identificar dónde se originan la mayoría de las asignaciones en el "heap". El perfil alloc_space es especialmente útil para esto.
- Aproveche el análisis de escape del compilador Go para optimizar dónde se almacenan los valores (ej. en la pila de goroutine en lugar del "heap"). Puede usar la bandera -gcflags=-m=3 con go build para ver por qué los valores escapan al "heap".

En resumen, Go promueve un estilo de manejo de errores explícito y basado en el control de flujo, utilizando múltiples valores de retorno para errores comunes y mecanismos de panic/recover para situaciones verdaderamente excepcionales, siempre en conjunto con defer para una gestión robusta de recursos. Herramientas como el detector de carreras de datos (go build -race) también son esenciales para prevenir errores relacionados con el acceso concurrente a la memoria.

Comentarios (4)4 comentarios

Moises Almonte

Me dio curiosidad como esta creada la librería de errores de Go, busque en el repo de Go en GitHub, el archivo errors.go

Este el código fuente:

URL:

José Antonio De La Paz Fonseca

Vivan los fundamentos

Ronaldo Jiménez

Lo que yo entiendo del tema, lo dejo por aquí:

Introducción y Configuración

Características y ventajas del lenguaje de programación Go

Instala Go en WSL con un comando

Paquetes en Go sin npm ni pip

Fundamentos de Go

Formas de declarar variables en Go

Conversión de tipos en Go

if else y operador módulo en Go

Cuatro formas de usar for en Go

Estructuras de Datos y Funciones

Sentencia switch en Go con ejemplos reales

Arreglos en Go: fijos e inferidos

Creación y uso de slices dinámicos en Go

Mapas en Go: creación, acceso y manipulación de datos clave-valor

Cómo crear y usar funciones personalizadas en Go

Retorno de múltiples valores en Go

Funciones variadic en Go con tres puntos

Funciones recursivas en Go con Fibonacci

Punteros en Go para optimizar rendimiento del sistema

Runas en Go: bytes vs caracteres reales

Declaración y uso de estructuras de datos en Go

Implementación de enumeradores en Go para controlar estados

Manejo de Errores y Concurrencia

Errores personalizados en Go

Goroutines y channels en Go

Select para ordenar goroutines en Go

Timeouts en goroutines con time.After

Workers en Go con goroutines y channels

Buenas Prácticas en Go

JSON con Marshal y Unmarshal en Go

Conversión de texto plano a hash con SHA256 en Go

Variables de ambiente en Go con paquetes externos

Cierre de curso de Go: consejos para consolidar el aprendizaje

Errores personalizados en Go