El peligro de los punteros nil en interfaces

En Go, una interfaz no es simplemente un puntero; es una estructura de datos compuesta por dos palabras: un type descriptor (que apunta a la información del tipo) y un data pointer (que apunta al valor real). Para que una interfaz sea considerada nil, ambos componentes deben ser nil. Si asignas un puntero nil de un tipo concreto a una interfaz, la interfaz dejará de ser nil porque ahora contiene información sobre el tipo, aunque el valor sea nulo.

Esto ocurre porque el runtime de Go necesita saber qué tabla de métodos (itables) debe consultar para ejecutar los métodos de una interfaz, y esa información reside en el descriptor de tipo. Si una función devuelve un puntero de un tipo personalizado (como *MyError) en lugar de la interfaz error directamente, y ese puntero es nil, estarás devolviendo una interfaz con un tipo definido pero un valor nil. Esto romperá cualquier validación posterior de if err != nil, ya que la comparación resultará en true, provocando errores lógicos o panics inesperados al intentar acceder a campos de un objeto que no existe.

Debes evitar este patrón siempre que tu función pueda devolver un error: nunca devuelvas un puntero con valor nil; devuelve siempre el literal nil para asegurar que la interfaz de retorno esté completamente vacía.

package main

import (
	"fmt"
)

// ServiceError es un tipo de error personalizado.
type ServiceError struct {
	Code    int
	Message string
}

// Error implementa la interfaz error.
func (e *ServiceError) Error() string {
	// Si e es nil, acceder a e.Message provocará un panic.
	return fmt.Sprintf("Código %d: %s", e.Code, e.Message)
}

// fetchData simula una operación de base de datos.
// El problema es que su firma devuelve el tipo concreto *ServiceError.
func fetchData(id int) *ServiceError {
	if id < 0 {
		return &ServiceError{Code: 400, Message: "ID inválido"}
	}
	// Devolvemos un puntero nil, pero con el tipo *ServiceError.
	return nil
}

func main() {
	ids := []int{42, -1}

	for _, id := range ids {
		fmt.Printf("--- Procesando ID: %d ---\n", id)

		// La variable 'err' es de tipo 'error' (la interfaz).
		// Al recibir el retorno de fetchData, se empaqueta el tipo y el valor.
		var err error = fetchData(id)

		// Aquí es donde ocurre el error lógico.
		// Para el ID 42, err no es nil porque su tipo es *ServiceError.
		if err != nil {
			fmt.Printf("Resultado: Se detectó un error: %v\n", err)
		} else {
			fmt.Println("Resultado: Operación exitosa")
		}
	}
}

En el ejemplo anterior, la función fetchData tiene una firma que retorna *ServiceError. Cuando el id es 42, la función ejecuta return nil. En ese instante, se está devolviendo un puntero nulo, pero con la información del tipo *ServiceError.

Al asignar ese resultado a la variable err (que es de tipo error), la interfaz se construye con Type: *ServiceError y Value: nil. Cuando el programa evalúa if err != nil, Go comprueba si la estructura de la interfaz está vacía. Como el descriptor de tipo no es nil, la condición se cumple y el programa entra en el bloque de error, imprimiendo Se detectó un error: <nil>. Si dentro de ese bloque intentáramos llamar a err.Error(), el programa sufriría un panic porque el método intentaría acceder a una dirección de memoria nula.

El error frecuente

// MAL: La función devuelve un puntero nil, no la interfaz nil.
func doWork() *MyError {
    var err *MyError = nil
    return err 
}

// Esto causará que 'err != nil' sea TRUE
err := doWork() 
if err != nil {
    // ... lógica de error que nunca debió ejecutarse
}

// BIEN: La función devuelve la interfaz directamente.
func doWork() error {
    var err *MyError = nil
    if err != nil {
        return err
    }
    return nil // Retorna el literal nil de la interfaz
}

Retornar nil explícitamente es la única forma de garantizar que la comparación de la interfaz funcione como esperas.

N° 78