[Informe de Clase] Desarrollo de Sistemas (2.º año), Semana 38

— Fortaleciendo el manejo de errores: diseñar cómo fallan los sistemas

Durante la Semana 38, usamos muchos de los bugs y excepciones descubiertos en las pruebas de integración de la semana pasada como material didáctico para estudiar de forma sistemática el manejo de errores: diseño de excepciones, validación de entrada y diseño de mensajes orientados al usuario.

Ahora que la app “funciona”, el profesor recalcó que también debemos diseñar cómo falla.

■ Introducción del profesor: “Las apps que ignoran errores no son de fiar”

Profesor Tanaka:
“Que algo funcione correctamente solo cuando todo va bien no es suficiente.
Un sistema profesional es aquel que está diseñado para comportarse correctamente incluso cuando algo va mal.”

El profesor comenzó revisando fallos representativos de las pruebas de integración de la semana pasada:

• Fallos al actualizar la base de datos → estado inconsistente, recuentos de inventario incorrectos
• Mensajes de excepción en bruto mostrados directamente en la UI (por ejemplo, un ValueError sin procesar)
• Excepciones no capturadas que provocan el cierre total de la app
• Registros de error insuficientes que impiden investigar la causa raíz

Estos se convirtieron en nuestros “ejemplos de libro de texto” para la lección de esta semana sobre cómo mejorar el manejo de errores.

■ Tres temas centrales de hoy

1. Validación de entrada (capa de UI)
2. Diseño de excepciones (capa de Servicio)
3. Registro y reporte de fallos (capa de Logging y DAO)

■ Ejercicio práctico ①: Validar entradas en la UI

Muchos bugs nacen de “entradas inesperadas”.
Por eso reforzamos el principio de hacer comprobaciones defensivas en la capa de UI.

Ejemplo: cuando se requiere un ID numérico

raw = input("Book ID: ")

if not raw.isdigit():
    print("Input Error: Please enter a numeric ID.")
    return
book_id = int(raw)

Estudiante A: “¡Solo añadir una comprobación numérica redujo nuestros errores a la mitad!”

Principios de validación (del profesor)

• Rechazar la entrada no válida lo antes posible en la UI
• Pero las comprobaciones de lógica de negocio pertenecen a la capa de Servicio
• Los mensajes de error deben estar escritos en palabras que el usuario entienda

■ Ejercicio práctico ②: Diseño de excepciones en la capa de Servicio (excepciones de dominio vs. del sistema)

La capa de Servicio maneja la lógica de negocio.
Al clasificar los errores, la legibilidad y mantenibilidad del código mejoran considerablemente.

Ejemplo: clases de excepción de dominio personalizadas

class BookNotFoundError(Exception):
    pass

class BookNotAvailableError(Exception):
    pass

Uso en la capa de Servicio

book = self.books_dao.get(book_id)
if not book:
    raise BookNotFoundError()

if not book.is_available:
    raise BookNotAvailableError()

La capa de UI responde después con mensajes apropiados al usuario según la excepción.

Estudiante B: “¡Ponerles nombre a las excepciones hace que el significado se entienda al instante!”

■ Ejercicio práctico ③: Manejo de fallos y gestión de transacciones en la capa DAO

Implementamos las siguientes protecciones en la capa DAO:

• Hacer siempre rollback de la transacción en caso de fallos de base de datos
• Registrar internamente los errores SQL (nunca mostrar detalles de BD en la UI)
• Los límites de las transacciones están controlados por la capa de Servicio

Ejemplo: manejo de excepciones dentro del DAO (versión de aprendizaje)

try:
    cur.execute("UPDATE books SET is_available=%s WHERE id=%s", (flag, book_id))
    self.conn.commit()
except Exception as e:
    self.conn.rollback()
    logger.error(f"DB Error: {e}")
    raise

Estudiante C: “¡Esto arregló el bug de ‘desajuste de inventario’ causado por un rollback que faltaba!”

■ Ejercicio práctico ④: Diseñar mensajes de error amigables para el usuario

Mostrar excepciones en bruto en la UI es un NO rotundo.
Practicamos reescribirlas en mensajes claros y amables.

Antes (mal ejemplo)

ValueError: invalid literal for int() with base 10

Después (mejorado)

Input Error: Please enter a numeric Book ID.

Puntos de aprendizaje

• Explicar exactamente qué estuvo mal
• Evitar expresiones que culpen al usuario
• Dar, cuando sea posible, una guía sobre cómo corregir la entrada

■ Ejercicio práctico ⑤: Diferenciar entre logs (para desarrolladores) y errores (para usuarios)

El profesor escribió esto en grande en la pizarra:

**Los logs son para desarrolladores

Los mensajes de error son para usuarios**

Patrón recomendado:

1. La capa de Servicio o DAO escribe logs detallados (uso interno)
2. La UI muestra un mensaje simple y educado (uso externo)

Estudiante D: “¡Es mucho más fácil investigar problemas cuando los logs incluyen el ID que falló!”

■ Mini ejercicio: enumerar 10 patrones de error

Cada grupo enumeró errores por categorías y debatió en qué capa debería manejarse cada uno:

• Errores de entrada
• Errores de autorización
• Errores de lógica de negocio
• Errores de integridad en DAO
• Fallos de APIs externas
• Fallos de transacción
• Excepciones inesperadas (y posibles comportamientos de fallback)

Estudiante E: “¡Una vez que categorizas los errores, el lugar correcto para manejarlos se vuelve obvio!”

■ Mensaje de cierre del profesor

“El manejo de errores es un mecanismo de seguridad.
Es la última línea de defensa que protege a los usuarios y sus datos.

Un sistema que ‘no se rompe aunque algo falle’
tiene muchísimo más valor que uno que solo funciona en condiciones ideales.

Lo que aprendisteis hoy será esencial para proyectos más grandes
y para el desarrollo colaborativo.”

■ Tareas (para el perfeccionamiento de la implementación de la próxima semana)

1. Crear una lista completa de errores para los casos de uso principales (trabajo en grupo)
2. Elaborar un conjunto de 10 mensajes de error mejorados y orientados al usuario
3. Entregar un mini informe de pruebas de integración que cubra la lógica de manejo de errores actualizada

■ Avance de la próxima semana: finalización de casos de uso y mini presentaciones

La próxima semana, presentaréis vuestros casos de uso completamente terminados,
incluyendo la capa de manejo de errores reforzada.
Será el momento de demostrar lo estable que se ha vuelto vuestra aplicación.

En la Semana 38, el alumnado se enfrentó a los errores de forma directa y dio un gran paso hacia la construcción de aplicaciones robustas y seguras para el usuario.
Están empezando a ver no solo la perspectiva del desarrollador,
sino también cómo diseñar pensando en la confianza y seguridad del usuario.