Errores y robustez
Cuando algo sale mal: códigos de error, excepciones, RAII al desenrollar la pila, garantías, optional, variant, expected, assert y tu propio framework de tests.
12 aulas · 10 horas de práctica · en el navegador, sin instalar nada
Temario
- Códigos de error o excepciones — Cuando una función no puede hacer lo que le pidieron, tiene que avisarle a quien la llamó. La forma más vieja es devolver un código: true o false, 0 o un número con nombre. Funciona... si alguien lo mira.
- throw, try y catch — Una función que no puede seguir tira una excepción con throw; el que sabe qué hacer la atrapa con try y catch. Entre los dos, todo lo que había en el medio se saltea: ni un if de más.
- std::exception y excepciones propias — Un error con nombre propio se atrapa aparte de los demás: la torre de control aterriza primero al vuelo sin combustible y desvía al que no entra. Cómo se arma la clase, el orden de los catch, los datos que viajan con el error y por qué se atrapa por referencia.
- Excepciones y RAII: el stack unwinding — Mientras una excepción sube buscando su catch, cada función que atraviesa se cierra y sus objetos mueren: corren sus destructores. Lo que es RAII se libera solo; un new a mano queda en el heap para siempre.
- noexcept y garantías — Atrapar un error no alcanza: ¿en qué estado quedó el objeto que se estaba cambiando? Las tres garantías (básica, fuerte y sin excepciones), cómo se consigue la fuerte trabajando sobre una copia, y noexcept, la promesa de no tirar.
- std::optional — No encontrar algo no es un error: es una respuesta. std::optional<T> es una caja que tiene un T o está vacía, y obliga a preguntar antes de abrirla. Adiós al -1 y al "" que se hacían pasar por datos.
- std::variant y visit — Una variable que puede ser una cosa u otra, y sabe cuál es: std::variant. Cómo se pregunta qué tiene, cómo se abre sin romperla, y visit, que obliga a decir qué hacer con cada caso.
- std::expected (C++23) — El resultado, o por qué no hubo resultado: std::expected junta lo mejor de los códigos de error y de las excepciones. Se mira como un optional, trae el motivo con error(), y se encadena con and_then.
- assert y static_assert — Hay errores que no son del mundo sino tuyos: un bug. assert frena el programa en la línea exacta donde algo que tenía que ser cierto no lo es, y static_assert lo frena antes, al compilar. Para bugs, no para lo que tipea la gente.
- Tu propio mini framework de tests — Un test es un programa chico que chequea que otro programa hace lo que tiene que hacer. Lo armás desde cero con lo del módulo: un chequear que anota, comparar con templates, chequear que algo tira, y un corredor que no se cae aunque un test explote.
- Taller — Parser de comandos a prueba de errores — La torre recibe órdenes por radio, en texto, y la radio no es confiable: números ilegibles, órdenes que no existen, datos que faltan, vuelos repetidos. Cada pieza del parser usa una herramienta del módulo, y la torre no se cae nunca.
- Taller — Cajero que nunca se cae — Un cajero automático no puede colgarse, ni dar plata que no hay, ni perder la que mueve. El pin tipeado mal, el saldo que no alcanza, los billetes que no cierran, la transferencia a medias y la fila de órdenes rotas: el módulo entero en una sola máquina.