05 - La Forja: las reglas que no se rompen

La versión actual tumba si se teclean letras en el nivel (NumberFormatException), el límite de niveles se corrige sin avisar y consultar un ítem que no está en la forja acaba en un null que nadie controla. El paso aplica el tema: jerarquía y tratamiento de excepciones (try/catch/finally, try-with-resources, throw/throws), excepciones personalizadas y ficheros de configuración.

• La aplicación no tumba por datos malos: letras donde van números, niveles imposibles, búsquedas fallidas, ítems inexistentes. El aviso sale, y el menú sigue vivo.
• Cada regla de negocio tiene su excepción con nombre: que el error de un héroe desaparecido no se disfraza de “error general”. Las propias, organizadas en una jerarquía breve; las de la plataforma, usadas donde la plataforma manda.
• Las reglas lanzan y el menú captura: la comprobación vive en la capa que conoce el dato (el setter que ya lo miraba, la búsqueda, la conversión del texto a número) y el punto único que decide se queda en el bucle del menú.
• Lo escrito en el código deja de ser la fuente de verdad: los límites y valores del gremio (capacidad, límites de nivel, bonos de clase…) salen a un fichero de configuración que la app lee al arrancar. El formato y las claves los eliges tú.
• Las pruebas de los pasos anteriores siguen pasando — sobre todo ahora, la que antes tumbaba el programa.

• Todo lo del tema: la jerarquía de excepciones, try/catch/finally, try-with-resources para las lecturas de ficheros, throw/throws, y la regla de la casa: la función que sabe lanza, la que decide captura.
• El parseo del fichero de configuración con java.util.Properties (u otro formato que sepas justificar), con los tres fallos clásicos controlados: fichero ausente, fichero ilegible y clave con formato imposible.
• Ojo con la conversión de texto a número: la del texto que teclea el usuario también es un punto de control. Decide si ahí se lanza o se vuelve a preguntar repitiendo el prompt, y sosténlo: el mensaje debe entender el usuario que teclea mal, no la máquina.

• ¿Qué errores son regla de negocio (excepción propia con nombre) y cuáles son de la plataforma? Y ¿tu jerarquía tiene una base propia o cada excepción va por libre?
• ¿Qué mensaje muestra cada excepción? Va a verse en consola: debe decir qué pasó y con qué dato, sin lenguaje de máquina.
• ¿Se relanza la lectura del prompt hasta que se teclea bien, o se avisa y se cancela la acción? Justifica el camino: cancelar deja el menú por encima de ese dato y relanzar lo devuelve al usuario las veces que haga falta.
• ¿Dónde se captura? Una captura única en el menú frente a capturas menudas repartidas por todo el código: elige y defídelo.
• ¿Qué va al fichero de configuración? Ni de más (claves que nadie lee) ni de menos (números que seguirán enterrados en el código). ¿Y qué pasa si el fichero no está o tiene una clave mal escrita?

• Teclear letras en el nivel no tumba la app: avisa con lo decidido y el menú sigue.
• Un nivel imposible no se guarda: el punto de control del 03 ahora lanza, no corrige en silencio.
• Buscar a un héroe que no existe muestra el mensaje de su excepción, igual que con los ítems de la forja.
• Borrar el fichero de configuración y arrancar la app: avisa de que no está y no entra en bucles raros; una clave mal escrita detecta y avisa igual.
• Cambiar un valor del fichero cambia el comportamiento de la app sin tocar el código — que era todo el punto.
• Las pruebas del paso 04 pasan enteras.

• Los informes del gremio (poder total, agrupación por clase, casillas…) siguen con bucles manuales → Stream/Optional (06).
• El fichero se parsea a mano y el proyecto no se construye ni comparte → paquetes, Maven y una librería de parseo (07).