🎮 UnityDocs

Excepciones en C#: try, catch y throw

Cómo manejar errores en C# con try/catch/finally, cuándo lanzar tus propias excepciones y —clave en Unity— por qué NO debes envolver toda tu lógica de juego en try/catch. La diferencia entre un error esperado y un bug.

📄 ArtículoIntermedio✅ RevisadoUnity 6.0 LTSActualizado 2026-07-17
DificultadConceptual Código Matemáticas
Tiempo📖 Lectura 7 min · ⌨️ Práctica 10 min

Qué es una excepción#

Una excepción es la forma que tiene C# de decir "ha pasado algo que no puedo resolver aquí": un archivo no existe, un texto no es un número, una división por cero. Si nadie la "atrapa", el programa corta la ejecución de ese método y sube el error. En Unity lo verás en la consola con su stack trace.

try / catch / finally#

C#
try
{
    string texto = File.ReadAllText(ruta);   // puede fallar (archivo inexistente)
    ProcesarPartida(texto);
}
catch (FileNotFoundException e)
{
    Debug.LogWarning("No hay guardado previo: " + e.Message);
    NuevaPartida();
}
finally
{
    // Se ejecuta SIEMPRE (haya error o no): ideal para cerrar/limpiar
    barraDeCarga.Ocultar();
}
  • try: el código que puede fallar.
  • catch (TipoException e): qué hacer si falla. Puedes tener varios catch para distintos tipos.
  • finally: se ejecuta pase lo que pase (liberar recursos, cerrar streams).

Lanzar tus propias excepciones#

Cuando un método recibe algo imposible, avisa con throw en vez de seguir con datos corruptos:

C#
public void Equipar(Arma arma)
{
    if (arma == null)
        throw new System.ArgumentNullException(nameof(arma), "No se puede equipar null");
    // ...
}

La regla de oro en Unity: no abuses del try/catch#

Un try/catch no arregla un bug: lo esconde

En Unity, un NullReferenceException o un IndexOutOfRange casi siempre son errores de programación (un bug), no situaciones que debas "manejar". Envolverlos en try/catch para que "no pete" oculta el problema y te deja un juego en estado corrupto. Arregla la causa, no tapes el síntoma. Ver NullReferenceException.

Reserva las excepciones para errores esperables y externos: entrada/salida de archivos, red, o datos que vienen de fuera (un JSON de guardado que puede estar corrupto).

Evita excepciones cuando puedas preverlas#

Para casos previsibles, el patrón Try... es más barato que un try/catch (no genera excepción):

C#
// ❌ Lanza y atrapa una excepción si el texto no es número (costoso)
try { edad = int.Parse(texto); } catch { edad = 0; }

// ✅ Sin excepción: devuelve true/false
if (!int.TryParse(texto, out int edad)) edad = 0;
Las excepciones son caras

Lanzar una excepción tiene coste (construye el stack trace). En bucles o en el Update, evita usarlas como control de flujo normal: usa comprobaciones (TryParse, TryGetComponent, comprobar != null) para lo que puedes prever.

Errores frecuentes#

  • catch (Exception) vacío que se traga todos los errores en silencio: nunca sabrás qué falló.
  • Envolver toda la lógica de juego en try/catch para "que no crashee" (esconde bugs).
  • Usar excepciones para flujo normal (existe TryParse, TryGetComponent).
  • Olvidar que finally corre siempre, incluso con return dentro del try.

Ponte a prueba#

📝 Pon a prueba lo aprendido

Resumen#

Las excepciones señalan errores que un método no puede resolver. Manéjalas con try/catch/finally, y lanza las tuyas con throw cuando recibas datos imposibles. En Unity, la clave es el criterio: usa excepciones para errores externos y esperables (archivos, red), y para lo previsible usa TryParse/TryGetComponent en vez de atrapar. No escondas bugs (NullReference, IndexOutOfRange) en un try/catch: arréglalos.

Fuentes y para profundizar