Si estás leyendo esto es porque la I1 de Programación Avanzada te salió más o menos bien: entendiste herencia, sobreviviste a las properties y tu código corría. Ahora te llega la materia de la I2 —excepciones, concurrencia, persistencia— y tienes la sensación de que es lo mismo pero con nombres más largos.

Esta guía parte de una tesis incómoda: en la I2 tu código puede correr perfecto y aun así perder la mitad del puntaje. Si en la I1 rescataste puntos “porque funcionaba”, esto te sirve. Si todavía no tienes claro qué es una instancia o para qué sirve super(), todavía no: eso se da por sabido, y conviene volver antes a la guía de la I1 de IIC2233.

La tesis: la I2 no pregunta si sabes escribirlo, pregunta si elegiste bien

En la primera mitad del ramo casi todas las preguntas tienen una respuesta estrecha: te piden una clase con cierto comportamiento, la escribes, y si hace lo que dice el enunciado estás bien. El código es la respuesta.

En la segunda mitad eso cambia en silencio. Los enunciados empiezan a decir “maneje adecuadamente los casos de error”, “sin que se bloquee la interfaz” o “de modo que la información persista entre ejecuciones”. Ninguna de esas frases te dice qué escribir: te dicen qué restricción respetar. Y hay varias implementaciones que corren, pero solo algunas la respetan.

Por eso la queja más común después de la I2 es “pero si a mí me funcionaba”. Claro que te funcionaba: lo probaste una vez, con un archivo que existía, con un hilo que alcanzó a terminar antes que el otro. La pauta no paga que corra en tu computador un martes. Paga que la decisión esté justificada.

El cambio de foco que casi nadie te avisa

Esta es la comparación que conviene tener a mano mientras estudias. No es el temario oficial —ese está en el programa de tu sección— sino el cambio de foco que casi nadie te dice explícitamente.

Excepciones: capturar de más reprueba igual que no capturar

Casi todos llegan a la I2 creyendo que el manejo de excepciones es “poner un try donde puede fallar”. Esa mitad la tienes; la otra es la que se pregunta.

Un except sin tipo, o un except Exception que abarca veinte líneas, no es defensivo: es ciego. Si te piden leer un archivo y envuelves la función entera en un try genérico, ese bloque también captura el KeyError de tu diccionario y el error de tipo de tres líneas más abajo. El programa no se cae, cierto, pero tampoco te avisa que está mal: la pauta lo lee como que no distingues entre errores esperables y bugs.

La regla práctica: captura el error específico, en el bloque más chico posible, y solo si sabes qué vas a hacer con él. Si tu except termina en un pass, pregúntate por qué lo capturaste. Los errores esperables —archivo que no existe, entrada que no es número, clave ausente— se manejan. Los bugs no se capturan: se arreglan.

El otro pedazo que se cobra son tus propias excepciones. Cuando el enunciado describe una condición del dominio (saldo insuficiente, jugador ya inscrito, sala llena), casi siempre esperan una clase que herede de Exception con un nombre que se lea solo. Es una respuesta corta y vale puntos completos.

Concurrencia: el error que no se reproduce dos veces igual

Los hilos son la parte de la I2 donde más gente se convence de que entendió sin haber entendido. La sintaxis es breve: creas un Thread, le pasas un objetivo, lo partes. Lo difícil es que el error típico de concurrencia no aparece cuando pruebas.

Si dos hilos leen y escriben la misma lista o el mismo contador, hay un momento en que uno lee un valor que el otro está a punto de cambiar. Puede que en diez ejecuciones no pase nada y a la undécima el resultado sea distinto. Ese es el punto de la materia: el estado compartido sin protección es un error aunque hoy no se note.

Para la prueba, ten claras tres cosas. Qué estado es compartido y cuál es local a cada hilo. Para qué sirve un Lock y por qué el bloque que protege tiene que ser corto. Y cuándo un hilo es la herramienta correcta: para tareas que esperan, no para hacer cálculos el doble de rápido. Si te preguntan “¿por qué usarías un hilo acá?” y respondes “para que sea más rápido”, esa casi nunca es la respuesta que pagan; la que pagan es “para que la interfaz siga respondiendo mientras esta tarea espera”.

Persistencia: elegir el formato ya es media respuesta

Cuando el enunciado dice que los datos deben sobrevivir al cierre del programa, no pide una función mágica: pide que elijas entre texto plano, CSV, JSON o binario, y que la elección tenga sentido con la forma del dato.

La heurística sirve casi siempre. Si tus datos son una tabla plana —filas iguales, campos simples—, CSV. Si tienen estructura anidada, listas dentro de diccionarios, objetos con atributos que son objetos, JSON. Si te piden guardar el objeto tal cual con su estado interno, ahí aparece la serialización binaria, con su advertencia: cómoda pero frágil, porque el archivo depende de la definición de la clase.

Lo que se penaliza no es elegir “mal”, es no justificar. Una línea que diga “uso JSON porque cada partida tiene una lista de jugadores anidada y CSV obligaría a aplanarla” convierte una pregunta de implementación en una respuesta completa. Y ojo: escribir en disco puede fallar, así que la persistencia es justo donde el manejo de excepciones vuelve a entrar.

Un plan de dos semanas escribiendo código, no leyendo

El plan que mejor funciona no es “leer los apuntes de nuevo”. Es escribir código chico y equivocarse a propósito, porque la I2 castiga decisiones y las decisiones solo se aprenden tomándolas.

Semana 1, un tema por día, media hora de lectura y una hora de teclado: excepciones propias, archivos con sus errores, hilos con un contador compartido —primero sin Lock, para ver el resultado inconsistente con tus propios ojos, y después con Lock— y serialización de una estructura anidada.

Semana 2, integración. Toma una tarea vieja del ramo y agrégale persistencia y manejo de errores. Después haz una I2 antigua cronometrada, a mano y sin ejecutar nada: es el ejercicio más incómodo y el que más se parece a la prueba real. El último día, solo revisar tus errores.

Si llevas Estructuras de Datos y Algoritmos en paralelo, no los estudies el mismo día: se parecen lo suficiente como para confundirse y evalúan cosas distintas.

Preguntas frecuentes sobre la I2 de IIC2233

¿Entra la materia de la I1?

De forma implícita, siempre. No te van a preguntar herencia por herencia, pero cualquier pregunta de la I2 te pide modelar con clases. Si esa base está débil, el problema aparece igual, solo que disfrazado de otra cosa.

¿Sirve estudiar solo con interrogaciones antiguas?

Sirven como diagnóstico, no como plan. Hazte una al principio para saber dónde estás, arregla lo que falló con ejercicios dirigidos y recién ahí haz las demás. Resolver seis seguidas sin corregir el patrón solo confirma el mismo error seis veces.

¿Cuánto código hay que escribir a mano?

Más del que te gustaría. Practica sin autocompletado al menos una vez por tema: importar lo que corresponde, escribir la firma completa, cerrar los bloques. Los puntos que se pierden por sintaxis en papel son evitables.

¿Y si me quedan cuatro días?

Prioriza así: día 1, excepciones —propias, específicas y con manejo real—; día 2, hilos con estado compartido y Lock; día 3, persistencia con los tres formatos y su justificación; día 4, una I2 antigua cronometrada y revisión de errores. No alcanza para todo, pero alcanza para lo que más pesa.

Si quieres ver los ejercicios resueltos

Si con esto ya sabes qué practicar, no necesitas nada más. Si prefieres ver los ejercicios resueltos con las decisiones explicadas en voz alta, revisa el curso de I2 de Programación Avanzada IIC2233. Y en el hub de la UC están las guías por curso del resto de tu semestre, ordenadas por interrogación.