Vas tancar el mòdul 5 amb un inventari honest: BiblioTech gestiona catàleg, préstecs, reserves, avisos i desfer, però és fràgil d'una manera que ja no es pot ignorar. Un Integer.parseInt("vint") tomba l'aplicació. Un false retornat no diu per què ha fallat. Un System.out.println("AVIS: ...") no es pot filtrar, arxivar ni tractar. I una operació que falla a mitges deixa el sistema incoherent.

Aquest mòdul ho resol, i comença pel més bàsic i alhora pel pitjor entès: què és realment una excepció. No és "un error que trenca el programa". És un objecte —amb la seva classe, el seu estat i els seus mètodes— que representa una fallada i que activa un mecanisme de transport molt particular: en comptes de retornar-se a qui crida com un valor, viatja cap enrere per la pila de crides buscant algú que se'n faci càrrec. Entendre aquest viatge és entendre tota la resta.

En aquesta lliçó no escriuràs ni un try ni un catch. Això és la lliçó següent. Aquí es tracta de llegir i comprendre la fallada: per què els codis de retorn són una solució pitjor, què passa exactament quan ningú no captura una excepció, com es llegeix un stack trace de dalt a baix —inclosa la secció Caused by:, que és on sol ser la veritat—, com està organitzada la jerarquia Throwable i què significa cada branca, i quina és la diferència entre excepcions comprovades i no comprovades, que és la decisió de disseny més discutida del llenguatge. Quan acabis, un bolcat d'excepció deixarà de ser un mur de text intimidant i passarà a ser el que realment és: un informe detallat que et diu exactament què ha fallat i on.

1. El punt de partida: el false mut de BiblioTech
2. Què és una excepció
3. Per què els codis de retorn són pitjors
4. Què passa quan ningú no captura: propagació per la pila
5. Anatomia d'un stack trace
6. Caused by:: la cadena de causes
7. La jerarquia de Throwable
8. Error: allò que no has d'intentar gestionar
9. RuntimeException: errors de programació
10. Les excepcions comprovades
11. Comprovades enfront de no comprovades: el criteri de disseny
12. El debat real sobre les excepcions comprovades
13. Els missatges de NullPointerException de Java 14+
14. Què no has de fer mai
15. Errors Comuns i Consells
16. Exercicis

Aquest és un mètode real del BiblioTech que vas construir al mòdul 5. Fixa-t'hi bé, perquè conté el problema que dona sentit a tot el mòdul:

El mètode funciona. Però mira què li arriba a qui el crida:

Aquest és el false mut: un valor que informa que alguna cosa ha anat malament, però que esborra tota la informació sobre què ha anat malament. Tres causes radicalment diferents —una fallada de programació (null), un conflicte de dades (referència repetida) i una violació d'una regla de negoci (ISBN ja catalogat)— col·lapsen en el mateix bit. I qui crida no pot reaccionar de manera diferent a cadascuna, perquè no sap quina ha passat.

Encara pitjor: el motiu real s'ha imprès per consola, on el programa no el pot llegir. Un System.out.println no és un canal de comunicació entre mètodes; és un abocador de text. Si registrar es crida des d'un servei web, des d'un procés per lots o des d'un test automatitzat, ningú no veu aquell avís.

I cercarPerReferencia encara és més perillós, perquè retorna null en el cas normal de "no existeix". El null viatja tan tranquil pel programa fins que algú l'utilitza:

L'explosió passa en un lloc diferent d'on hi havia el problema. L'error real va ser a la línia 1 (cercar una cosa que no existeix); el símptoma apareix a la línia 2. Aquest desplaçament entre causa i símptoma és una de les fonts més grans de temps perdut depurant.

Les excepcions resolen exactament això: permeten assenyalar una fallada amb nom, amb dades i en el moment exacte en què es detecta.

Una excepció és un objecte Java, instància d'una classe que descendeix de java.lang.Throwable, que representa una condició anòmala durant l'execució del programa.

Les tres paraules importants d'aquesta definició:

• Objecte: no és una paraula clau màgica ni un codi numèric. És un objecte normal, amb el seu tipus, els seus camps i els seus mètodes. Es pot crear amb new, guardar en una variable, passar com a paràmetre i fins i tot emmagatzemar en una llista. El que el fa especial és com es transporta.
• Representa una condició anòmala: un fitxer que no hi és, un número mal escrit, un índex fora de rang, una regla de negoci violada. Alguna cosa que impedeix al mètode complir el seu contracte.
• Durant l'execució: no és un error de compilació. El codi compila perfectament; la fallada apareix quan s'executa amb unes dades determinades.

Mira qualsevol excepció com el que és —un objecte amb estat:

Sortida:

Tres observacions que convé gravar des del principi:

1. Crear una excepció no la llança. L'objecte existeix, però el flux del programa no s'altera. Llançar-la requereix la paraula throw, que veuràs a 06-03.
2. L'objecte ja conté la pila de crides en el moment de la seva construcció (getStackTrace() retorna un array de marcs). Aquesta captura passa al constructor, no en llançar-la. És la part més costosa de crear una excepció, i tornarà a aparèixer a 06-02 en parlar de rendiment.
3. El missatge és text lliure, i la seva qualitat depèn enterament de qui l'escriu. "error" i "La tarifa diaria no pot ser negativa: -0.25" costen el mateix; només un dels dos serveix per a alguna cosa.

Quan una excepció es llança, passen dues coses simultànies:

• L'execució del mètode s'interromp immediatament en aquell punt. Les línies següents del mètode no s'executen.
• L'objecte excepció comença a propagar-se cap enrere per la pila de crides, buscant un gestor. Aquest viatge és l'apartat 4.

Abans de les excepcions —i encara avui en llenguatges com C o Go— les fallades es comuniquen amb el valor de retorn: -1, null, false, un codi numèric. Java permet fer-ho, i de vegades fins i tot és el correcte. Però com a mecanisme general té quatre defectes greus.

El primer defecte és el decisiu. Compara:

Amb el booleà, el programa continua amb una premissa falsa: creu que el material està registrat i no ho està. Els errors que es propaguen silenciosament contaminant l'estat són molt més cars de diagnosticar que els que aturen el programa, perquè el símptoma apareix minuts o hores després, en un altre lloc, sense relació aparent amb la causa.

El quart defecte, la contaminació de qui crida, es veu millor amb un flux complet. Així queda un préstec amb codis de retorn:

Cinc if de guarda, cinc return false indistingibles, i qui cridi prestar rebrà un sol booleà amb cinc significats possibles. I encara més, cadascun d'aquests false que retorna prestar acabarà convertit en un altre false a la capa superior, perdent encara més informació a cada salt.

Al final del mòdul, aquest mateix mètode llançarà MaterialNoTrobatException, MaterialNoDisponibleException, EmpleatDesconegutException o LimitPrestecsExceditException, cadascuna amb les dades concretes de la fallada, i la capa de presentació podrà decidir quin missatge mostrar en cada cas.

Dit això, els codis de retorn no sempre són dolents. Map.get retornant null i Set.add retornant false són dissenys perfectament raonables, perquè en aquests casos "no hi és" i "ja hi era" són resultats normals, no fallades. La regla informal és: si la condició forma part del funcionament esperat i qui crida la comprovarà sempre, un valor de retorn està bé; si és una fallada que impedeix complir el contracte del mètode, és una excepció. A 06-07 tornaràs sobre aquest criteri amb una taula completa.

Aquí hi ha el mecanisme central del mòdul. Recupera la pila de crides de 05-08: cada vegada que un mètode en crida un altre, la JVM apila un marc (stack frame) amb les variables locals i el punt de retorn; quan el mètode acaba, el seu marc es desapila.

Quan es llança una excepció, aquest desapilat passa de cop i sense executar la resta dels mètodes. És el que s'anomena desenrotllament de la pila (stack unwinding).

Observa un cas concret de BiblioTech:

Sortida real:

Els missatges 2 i 4 no apareixen. No és que se'ls hagin saltat: és que els seus mètodes van ser abandonats a mitja execució. Cap línia posterior al punt de llançament no va arribar a executar-se en cap dels mètodes de la cadena.

Aquest és el viatge complet:

Els passos, en detall:

1. Integer.parseInt detecta que "dotze" no és un número i llança un objecte NumberFormatException.
2. La JVM busca al mètode actual un gestor (catch) capaç de tractar aquell tipus. No n'hi ha. Descarta el marc de parseInt.
3. Puja a qui l'ha cridat, calcularDies. Tampoc no hi ha catch. Descarta el seu marc. El return no es completa mai.
4. Puja a processarSolicitud. Tampoc. Descarta el seu marc. La línia del println("4. ...") queda sense executar.
5. Puja a main. Tampoc. Descarta el seu marc.
6. Ja no hi ha més marcs: l'excepció arriba al gestor d'excepcions no capturades per defecte del fil, que imprimeix Exception in thread "main" ... seguit del stack trace a System.err (no a System.out).
7. El fil main acaba. Si no queden altres fils no daemon vius, la JVM s'apaga amb un codi de sortida diferent de zero (típicament 1), que és el que un script o un sistema d'integració contínua interpreta com "aquest procés ha fallat".

Tres precisions importants que gairebé ningú no explica:

• Acaba el fil, no necessàriament la JVM. En un programa d'un sol fil, coincideixen. Però si una excepció escapa d'un fil secundari (mòdul 8), aquell fil mor i la resta del programa segueix funcionant, sovint sense que ningú se n'assabenti. És una font clàssica de fallades silencioses.
• El stack trace s'imprimeix a System.err. Si redirigeixes la sortida estàndard a un fitxer però no la d'error, o a l'inrevés, veuràs la meitat de la història. I com que System.out i System.err es buiden de manera independent, és habitual que a la consola apareguin barrejats i desordenats, cosa que despista molt en depurar.
• Es pot substituir aquest gestor per defecte. Thread.setDefaultUncaughtExceptionHandler permet decidir què passa amb les excepcions que escapen de tot. És una de les peces de la "frontera d'errors" que muntaràs a 06-07.

A 02-05 vas aprendre a llegir un stack trace com a eina de depuració. Ara toca la lectura completa i precisa, perquè el stack trace és el document més valuós que tens quan alguna cosa falla en producció i no la pots reproduir.

Torna al bolcat de l'apartat anterior, ara anotat:

I ara la regla d'or per llegir-lo:

La primera línia at és on ha passat la fallada. L'última és on ha començat tot. El teu codi sol ser al mig.

L'ordre és del cim al fons de la pila, és a dir, del punt més profund cap enrere. Per això main sempre apareix al final: és el fons de la pila.

Estratègia pràctica de lectura, en aquest ordre:

1. Llegeix la classe i el missatge (línia 1). Moltes vegades amb això n'hi ha prou: NumberFormatException: For input string: "dotze" és un diagnòstic complet.
2. Baixa fins a la primera línia que contingui el teu paquet (com.nexussoftware.bibliotech). Les línies de java.base/..., de Spring, d'Hibernate o de qualsevol llibreria solen ser només el camí; l'error gairebé sempre és en com tu les vas cridar. A l'exemple, DemoPropagacio.calcularDies(DemoPropagacio.java:17) és la primera línia "teva": aquí hi ha el problema.
3. Continua baixant per reconstruir el camí: qui ha cridat qui i amb quines dades. Això et diu com s'ha arribat a aquella situació, que és el que sol faltar.
4. Busca Caused by:, si n'hi ha. És l'apartat següent, i és on hi ha la veritat a les aplicacions amb frameworks.

Un detall que confon molta gent: a l'exemple, Integer.parseInt apareix dues vegades amb línies diferents (665 i 781). No és un error del bolcat: parseInt(String) és una sobrecàrrega que crida internament parseInt(String, int radix). Cada marc és una invocació diferent, encara que el nom del mètode es repeteixi.

Una altra observació: java.base/ davant del nom de la classe és el mòdul de la plataforma (JPMS, Java 9+, tema de 10-06). Indica que aquella classe ve del JDK, no del teu codi ni d'una llibreria. És un filtre visual molt útil: tot el que comença per java.base/ és de la biblioteca estàndard.

Finalment, dos casos que sorprenen:

• Stack traces truncats amb ... 23 more. Java no repeteix els marcs comuns entre una excepció i la seva causa. ... 23 more significa "els 23 marcs següents són idèntics als del bloc anterior". No és informació perduda.
• Traces buits o sense línies. Amb l'optimització del JIT, certes excepcions molt repetides (com les NullPointerException llançades en un bucle calent) poden acabar llançant-se sense stack trace per una optimització anomenada fast throw. Si veus una excepció sense trace, arrenca-la amb -XX:-OmitStackTraceInFastThrow i tornarà a aparèixer complet.

En una aplicació real amb capes —i BiblioTech ho serà al final d'aquest mòdul—, una excepció de baix nivell s'embolcalla en una altra de més alt nivell abans de continuar pujant. El resultat és una cadena de causes, i el stack trace les mostra totes.

Un exemple amb l'estructura típica de tres capes:

Com es llegeix això:

Regla pràctica: llegeix la primera línia per saber quina operació ha fallat i baixa a l'últim Caused by: per saber per què. El mig és el camí entre totes dues.

A l'exemple, l'operació que ha fallat és "registrar un préstec" (bloc 1), la raó immediata és que el material no estava disponible (bloc 2), però la causa arrel és un comptador de préstecs que s'ha tornat negatiu (bloc 3). Arreglar el nivell superior no serviria de res: el problema és a Empleat.registrarPrestec.

I aquí una avançada important de 06-03: aquesta cadena només existeix si qui embolcalla l'excepció en conserva la causa. Si a GestorPrestecs.prestar algú hagués escrit:

...el stack trace s'hauria quedat al primer bloc, i els dos Caused by: —els que contenen la informació útil— haurien desaparegut per sempre. Aquest error, que a 06-03 anomenaràs "perdre la causa", és responsable d'una quantitat enorme d'hores malgastades en producció.

Tot el que es pot llançar en Java descendeix d'una única classe: java.lang.Throwable. La seva descendència s'organitza així:

Aquesta jerarquia no és decorativa. Té tres conseqüències pràctiques que governen tota la resta:

1. Només es poden llançar i capturar objectes que descendeixin de Throwable. No pots llançar un String ni un int.
2. La branca determina si el compilador t'obliga a alguna cosa. Exception (excloent-hi RuntimeException) és comprovada: el compilador exigeix capturar-la o declarar-la. Error i RuntimeException són no comprovades: el compilador no diu res.
3. Capturar una superclasse captura tots els seus descendents. catch (Exception e) captura també NumberFormatException, perquè en descendeix. Això és el que dona sentit —i perill— a les captures amples, i el que fa obligatori l'ordre dels catch que veuràs a 06-02.

El que Throwable aporta a tots els seus descendents:

Fixa't que Throwable té dos fills directes amb destins oposats: Error, que no has de gestionar, i Exception, que sí. Aquesta separació és el motiu pel qual mai no es captura Throwable: fer-ho posa al mateix sac coses que es tracten de manera completament diferent.

La branca Error representa fallades de la màquina virtual o de l'entorn, no de la lògica del teu programa. Són situacions de les quals, en general, una aplicació no es pot recuperar de manera sensata.

El StackOverflowError és el més fàcil de provocar, i ja el coneixes del mòdul 5:

El seu stack trace és recognoscible a l'instant: milers de línies idèntiques repetides.

Quan vegis això, no busquis l'error a la línia que es repeteix: busca'l a la condició d'aturada que falta o que no es compleix mai.

La regla amb els Error és taxativa: no els capturis. Si el teu programa es queda sense memòria, capturar l'OutOfMemoryError no arregla res —el més probable és que el següent new torni a fallar, i a més el mateix gestor pot necessitar memòria per executar-se—. La resposta correcta és deixar que el procés mori, que un supervisor el reiniciï, i analitzar-ne la causa: un bolcat de monticle, una fuita, un límit mal dimensionat. Això és matèria de 10-07.

L'única excepció raonable a aquesta regla és un servidor d'aplicacions o un framework que captura Throwable al seu bucle principal per registrar-lo abans de morir, mai per continuar com si res. Tu, escrivint lògica de negoci, no tens aquest cas.

RuntimeException i els seus descendents són excepcions no comprovades: el compilador no obliga a capturar-les ni a declarar-les. El criteri de disseny darrere d'aquesta decisió és clar i mereix recordar-se:

Una RuntimeException assenyala normalment un error de programació: alguna cosa que no hauria d'haver passat si el codi estigués ben escrit. La solució no és capturar-la, és corregir el codi.

Aquestes són les que veuràs més, amb la seva causa típica i el seu remei real:

Un programa curt que en provoca diverses a propòsit, per reconèixer-les pel seu missatge:

Presta atenció a un detall del cas 4: la divisió entera per zero llança excepció, però la divisió en coma flotant no. 30 / 0 explota; 30.0 / 0.0 retorna NaN i 30.0 / 0 retorna Infinity, en silenci. És una asimetria de l'especificació IEEE 754 que sorprèn, i una font real de càlculs de multes absurds: si TARIFA_DIARIA es dividís accidentalment per zero, BiblioTech no fallaria, simplement començaria a mostrar Infinity € als rebuts.

Una excepció comprovada (checked) és qualsevol descendent d'Exception que no descendeixi de RuntimeException. Sobre aquestes el compilador aplica l'anomenada regla de capturar o declarar (catch or specify): si un mètode les pot llançar, qui el crida està obligat a fer una de dues coses.

Comprova-ho tu mateix. Aquest codi no compila:

El compilador es planta. Les dues sortides legals seran les de 06-02 i 06-03: capturar-la amb try-catch, o declarar-la amb throws a la signatura perquè el problema sigui de qui crida.

Aquestes són les comprovades més freqüents:

La intenció original del disseny és aquesta: una excepció comprovada representa una condició anòmala però previsible i potencialment recuperable, aliena al control del programador. Que un fitxer no existeixi no és un error del teu codi: és un fet del món. Per això el llenguatge t'obliga a decidir explícitament què fer-hi, en comptes de deixar que el programa caigui.

Aquesta taula resumeix la diferència completa, i convé tornar-hi quan a 06-04 hagis de triar de quina classe hereten les teves pròpies excepcions:

La pregunta que t'ajudarà a decidir a la pràctica:

Pot qui crida fer alguna cosa sensata i diferent de "morir" quan això passi?

• Sí → una comprovada és defensable: demanar el fitxer un altre cop, fer servir valors per defecte, reintentar.
• No, això no hauria de passar mai si el codi està bé → no comprovada.

Aplicat a BiblioTech, que és la decisió que prendràs formalment a 06-04:

Java és pràcticament l'únic llenguatge majoritari amb excepcions comprovades. C#, Kotlin, Scala, Python, JavaScript i Go les van descartar deliberadament. Convé que coneguis el debat, perquè marca l'estil del codi modern que et trobaràs.

A favor de les comprovades:

• Fan visible a la signatura què pot fallar. L'API es documenta sola.
• Impedeixen oblidar una fallada previsible: el compilador no deixa compilar.
• Obliguen a pensar en el camí d'error en el moment d'escriure el codi, no quan ja és en producció.

En contra:

• Contaminen les signatures. Si un mètode profund llança IOException, tota la cadena fins a dalt l'ha de declarar o capturar. Un canvi intern es converteix en un canvi d'API.
• Empenyen cap a l'antipatró. Davant de l'obligació, molta gent escriu el catch buit o el catch (Exception e) { e.printStackTrace(); }, que és pitjor que no haver capturat res: el programa continua amb l'estat trencat i sense que ningú se n'assabenti.
• Trenquen amb les lambdes. Les interfícies funcionals de java.util.function que vas conèixer a 04-06 no declaren excepcions comprovades, així que no pots llançar una IOException des de dins d'un Function o un Consumer sense embolcallar-la. Això es va tornar molt incòmode a partir de Java 8, i és una de les raons de pes del gir modern cap a les no comprovades.

On és el consens avui: els frameworks moderns han votat amb els peus. Spring converteix totes les SQLException (comprovades) en la seva jerarquia DataAccessException (no comprovades). Hibernate fa el mateix. La majoria de llibreries noves fan servir exclusivament no comprovades.

La postura pragmàtica, que és la que seguiràs en aquest mòdul:

• Fes servir no comprovades per defecte per als errors del teu domini.
• Reserva les comprovades per a condicions externes on qui crida realment farà alguna cosa diferent de propagar.
• Mai no silenciïs una comprovada amb un catch buit per treure-te-la de sobre. Si de debò no pots fer res útil allà, embolcalla-la en una de no comprovada conservant-ne la causa (06-03) i deixa que pugi.

La NullPointerException ha estat històricament l'excepció més frustrant de Java, per una raó molt concreta: no deia quina de les referències de la línia era null. Davant d'això:

...un NullPointerException en Java 8 et donava això:

Era cataleg el nul? El resultat de cercarPerReferencia? El de getFitxa()? L'única sortida era partir la línia en diverses o obrir el depurador.

Des de Java 14, amb les helpful NullPointerExceptions (activades per defecte des de Java 15), el missatge és aquest:

El missatge assenyala amb precisió quirúrgica: el valor retornat per cercarPerReferencia era null. Diagnòstic resolt sense depurador i sense tocar el codi.

La JVM sap construir aquests missatges per a tots els casos en què un null provoca la fallada:

Aquest últim és el que explica el clàssic NullPointerException "impossible" que et pot donar un Map<String, Integer>:

El null retornat per get s'intenta desempaquetar a int (autounboxing, mòdul 1), cosa que implica cridar intValue() sobre null. El missatge detallat ho diu exactament. Sense ell, aquesta fallada desconcerta durant una bona estona.

Com que fas servir Java 17 o superior, tens això activat per defecte i de franc. Aprofita-ho: quan vegis una NullPointerException, llegeix el missatge complet abans de tocar res. Gairebé sempre t'està donant la resposta ja mastegada.

Abans d'escriure el teu primer try a la lliçó següent, tres regles que no admeten matisos. Les veuràs demostrades amb codi a 06-02; aquí van els principis.

1. No capturis Throwable.

Capturar Throwable posa al mateix sac el teu error de negoci i un OutOfMemoryError o un StackOverflowError, dels quals no et pots recuperar. Encara pitjor: atrapa també ThreadDeath i errors del carregador de classes, amb els quals interferir pot deixar la JVM en un estat impossible de diagnosticar. Captura el tipus més específic que sàpigues gestionar.

2. No capturis i et quedis callat.

Això no gestiona l'error: el destrueix. L'excepció duia a dins la classe, el missatge, la causa i la pila completa; tot això es perd per sempre i el programa continua fingint que l'operació ha tingut èxit. Una fallada així pot trigar setmanes a manifestar-se, i quan ho faci no en quedarà ni rastre de l'origen. Si el catch és buit, és que estava malament capturar-la.

Un catch buit només és admissible en un cas, i amb comentari obligatori explicant per què la fallada és realment irrellevant allà.

3. No facis servir excepcions per al flux normal.

A part de ser il·legible, això és ordres de magnitud més lent que un for normal, perquè construir l'objecte excepció implica capturar la pila de crides completa. Les excepcions són per al que és excepcional. En veuràs els números a 06-02.

Creure que una excepció "trenca el programa" i prou. No: activa un mecanisme molt definit —desenrotllament de la pila buscant un gestor— que pots controlar completament. Només acaba el fil si ningú no la gestiona en tot el recorregut.

Llegir el stack trace de baix a dalt. Es llegeix de dalt a baix. La primera línia at és el punt exacte de la fallada; l'última és main. I si hi ha Caused by:, la veritat sol ser a l'últim d'ells.

Ignorar les línies del stack trace que no són teves. Correcte com a filtre inicial: busca la primera línia amb el teu paquet. Però no les esborris de l'informe d'error: el camí per dins de la llibreria de vegades és justament el que revela l'ús incorrecte.

Pensar que Exception inclou tot allò llançable. No inclou Error. catch (Exception e) no atrapa un OutOfMemoryError. En aquest cas concret, aquesta limitació és una virtut.

Confondre Error amb error. En Java, Error és una branca concreta de la jerarquia —fallades de la JVM—, no un sinònim genèric de "alguna cosa ha anat malament". Un NullPointerException no és un Error.

Creure que una excepció no comprovada és "menys greu". És exactament al revés: normalment indica un defecte en el teu codi, mentre que una de comprovada sol indicar una circumstància de l'entorn. La paraula "comprovada" descriu què fa el compilador, no la gravetat.

Escriure missatges d'excepció inútils. "Error", "Fallada" o "No s'ha pogut" no ajuden ningú a les tres de la matinada. Un bon missatge diu què ha passat, amb quina dada concreta i què s'esperava: "Referencia duplicada: LIB-0001 ja existeix al cataleg". És la mateixa quantitat de feina.

Consell: davant d'una NullPointerException, llegeix el missatge sencer. Des de Java 14 et diu literalment quina referència era nul·la. És la millora de diagnòstic més rendible de l'última dècada de Java.

Consell: quan reportis un error, copia el stack trace COMPLET. Inclosos tots els Caused by: i els ... N more. Un trace retallat a la primera línia sol eliminar precisament la informació que resolia el cas.

Consell: en producció, redirigeix System.err a un fitxer. Si no, els stack traces es perden tan bon punt es tanca el terminal. A 06-07 faràs això correctament, amb un Logger i un FileHandler.

Consell: -XX:-OmitStackTraceInFastThrow. Si en producció apareixen excepcions sense stack trace, és l'optimització fast throw del JIT. Aquest paràmetre la desactiva i retorna els traces complets mentre diagnostiques.

Escriu la classe ZoologicExcepcions al paquet com.nexussoftware.bibliotech.presentacio amb un main que, sense fer servir try ni catch (encara no toca), provoqui de manera controlada les excepcions següents, una per execució segons un argument numèric, i que abans de cadascuna imprimeixi què passarà i per què:

1. NullPointerException en demanar el títol d'un material que cercarPerReferencia ha retornat com a null.
2. ArrayIndexOutOfBoundsException en recórrer un array d'ISBN amb <= en comptes de <.
3. NumberFormatException en convertir l'entrada "quinze dies" amb Integer.parseInt.
4. ArithmeticException en calcular la mitjana de dies de préstec amb zero préstecs.
5. ClassCastException en convertir un Object que conté un String a Integer.
6. UnsupportedOperationException en afegir un material a una llista creada amb List.of.
7. ConcurrentModificationException en eliminar d'una llista dins d'un for-each.

Per a cada cas, executa el programa i anota en un comentari al final del fitxer el missatge exacte que produeix cada excepció al teu JDK.

T'arriba aquest bolcat des de l'entorn de producció de Nexus Software:

Respon per escrit, justificant cada resposta amb la línia concreta del bolcat:

1. Quin fil ha mort?
2. Quina operació de negoci ha fallat, en llenguatge planer?
3. Quina és la causa arrel exacta?
4. En quin fitxer i línia començaries a investigar? Per què aquella i no la primera línia at?
5. Què significa ... 3 more?
6. Quants marcs tenia la pila en total en el moment de la fallada original?
7. És aquest un error de programació o una condició de l'entorn? Quina branca de la jerarquia ho confirma?
8. Proposa dues correccions: una que eviti el símptoma i una altra que ataqui la causa arrel. Quina és la bona?

Escriu ClassificadorExcepcions, una utilitat que rebi un objecte Throwable ja construït (no llançat) i produeixi un informe amb:

• El nom simple i el nom complet de la classe.
• Si és un Error, una excepció comprovada o una no comprovada. Pista: t instanceof Error, t instanceof RuntimeException, i en cas contrari és comprovada.
• La reacció recomanada, segons una taula que defineixis tu ("No gestionar: deixar morir el proces", "Corregir el codi", "Gestionar: es una condicio externa").
• La cadena completa de causes, sagnada per nivells, recorrent amb getCause() fins a arribar a null.
• El nombre de marcs de la seva pila i el primer marc que pertanyi al paquet com.nexussoftware, si n'hi ha.

Al main, construeix a mà una cadena de tres excepcions imbricades —una IllegalStateException causada per una RuntimeException causada per una java.io.IOException— i passa-la al classificador. Vigila amb les cadenes circulars: protegeix el recorregut amb un límit de profunditat.

Solució 1

Solució 2

1. Quin fil ha mort? El fil "main", segons la primera línia: Exception in thread "main". En ser l'únic fil del programa, la JVM acaba amb codi de sortida diferent de zero.

2. Quina operació de negoci ha fallat? Emetre el rebut de la devolució del préstec PR-0007. Ho diuen conjuntament el missatge de l'excepció de més alt nivell (No s'ha pogut generar el rebut del prestec PR-0007) i el camí de crides: main → opcioRetornar → retornar → emetre. L'usuari va triar l'opció "retornar" del menú.

3. Quina és la causa arrel exacta? El camp titular de l'objecte Prestec val null. Ho diu l'últim Caused by:, i amb la precisió dels missatges de Java 14+: Cannot invoke "...Empleat.getNom()" because "this.titular" is null. El this.titular indica que no és una variable local ni un paràmetre, sinó un camp del mateix Prestec: l'objecte es va construir sense titular o algú el va posar a null després.

4. On començar a investigar? A Prestec.java:97, dins de descripcioTitular, que és la primera línia at de l'últim Caused by:. Aquí és on el null es manifesta. No a la primera línia del bolcat (RebutConsola.java:54), perquè aquesta és només la capa que va embolcallar la fallada, no la que la va produir.

Ara bé, el lloc on es manifesta no és necessàriament on hi ha el defecte: el veritablement sospitós és com un Prestec va arribar a existir amb titular a null. La investigació real és al constructor de Prestec i a GestorPrestecs, que és qui els crea.

5. Què significa ... 3 more? Que els 3 marcs següents de la causa són idèntics als del bloc anterior i Java no els repeteix. Reconstruïts, són GestorPrestecs.retornar, MenuBiblioTech.opcioRetornar i BiblioTechApp.main. No hi ha informació perduda.

6. Quants marcs tenia la pila? Cinc. Els dos explícits de la causa (Prestec.descripcioTitular i RebutConsola.emetre) més els 3 comprimits al ... 3 more. La pila completa era:

Detall fi: RebutConsola.emetre apareix a la línia 51 a la causa i a la 54 a l'embolcall. Coherent: a la 51 es va cridar descripcioTitular i va fallar; a la 54 hi ha el catch que la va embolcallar en la IllegalStateException.

7. Error de programació o condició de l'entorn? Error de programació. Ho confirma la branca de la jerarquia: NullPointerException descendeix de RuntimeException, és a dir, és no comprovada. Res extern no ha fallat —ni disc, ni xarxa, ni entrada d'usuari—: simplement existeix un objecte de domini en un estat invàlid que mai no s'hauria d'haver permès.

8. Dues correccions.

Correcció del símptoma (dolenta com a única solució):

El rebut s'emet, però sense titular, i el préstec continua estant corrupte en memòria i en qualsevol informe posterior. S'ha silenciat l'avís, no arreglat el problema.

Correcció de la causa (la bona): impedir que un Prestec pugui existir sense titular, validant al constructor —exactament el que faràs a 06-03:

Així la fallada es detecta en el moment i el lloc en què es crea l'objecte invàlid, amb un missatge clar, en comptes de vint minuts després en imprimir un rebut. És el principi de fallar ràpid (fail-fast) que desenvoluparàs a 06-03.

Solució 3

Sortida (abreujada):

Dos aprenentatges de l'exercici:

1. L'ordre dels instanceof a categoria és obligatori. Si preguntessis primer t instanceof Exception, tota RuntimeException hi cauria i es classificaria malament, perquè RuntimeException és una Exception. Aquesta mateixa regla —del que és específic al que és general— serà la regla d'ordre dels blocs catch a 06-02, només que allà el compilador t'obligarà a respectar-la.
2. La cadena de causes es recorre amb getCause() fins a null, i l'última de la cadena és la causa arrel. És exactament el que fa la JVM en imprimir els blocs Caused by:. En implementar-ho tu, entens que aquell format del stack trace no és màgia: és un recorregut trivial sobre una llista enllaçada d'excepcions.

Ja saps què és realment una excepció: un objecte que representa una fallada, que es construeix amb new com qualsevol altre, que duu a dins la seva classe, el seu missatge, la seva causa i una fotografia completa de la pila de crides, i que —quan es llança— interromp el mètode en sec i viatja cap enrere per la pila buscant qui se'n faci càrrec.

Entens per què això és millor que els codis de retorn: un false es pot ignorar en silenci, no diu per què ha fallat, ocupa el valor de retorn i obliga a comprovar a cada crida. El false mut de Cataleg.registrar i el null de cercarPerReferencia són, exactament, la primera fragilitat que aquest mòdul eliminarà.

Coneixes el mecanisme complet del desenrotllament de la pila: la JVM busca un gestor marc a marc, descartant cadascun sense executar la resta del seu codi, i si arriba al fons sense trobar-lo, lliura l'excepció al gestor per defecte del fil, que imprimeix el trace a System.err i acaba el fil —no necessàriament la JVM, matís que tornarà al mòdul 8—, deixant un codi de sortida diferent de zero.

Saps llegir un stack trace de dalt a baix, identificant el fil, la classe de l'excepció, el missatge i cada marc amb el seu fitxer i la seva línia; saps que la primera línia at és el punt de la fallada, que l'última és main, que convé saltar a la primera línia del teu propi paquet, i que davant d'una cadena de Caused by: la veritat és a l'últim. També saps que ... N more no amaga informació, i que un trace absent pot ser cosa de l'optimització fast throw.

Tens el mapa de la jerarquia: Throwable a l'arrel, amb Error per a les fallades de la JVM que no has de gestionar —StackOverflowError, OutOfMemoryError—, i Exception per a les condicions anòmales, amb la seva branca RuntimeException d'errors de programació. Reconeixes les excepcions més freqüents de cada branca pel seu nom i pel seu missatge, saps que la divisió entera per zero explota mentre que la de coma flotant retorna Infinity en silenci, i saps que els missatges detallats de NullPointerException de Java 14+ et diuen literalment quina referència era nul·la.

I tens clara la distinció entre comprovades i no comprovades: què obliga el compilador en cada cas, el criteri de disseny —condició externa recuperable enfront de defecte del codi—, el debat real sobre el seu valor, i la postura pragmàtica que seguiràs a BiblioTech: no comprovades per defecte per al domini, comprovades només quan qui crida faci alguna cosa diferent de propagar. Juntament amb les tres prohibicions que no admeten matisos: no capturis Throwable, no capturis sense fer res, i no facis servir excepcions per al flux normal.

Fins aquí has après a llegir la fallada. A la lliçó següent, Bloc Try-Catch, aprendràs a gestionar-la: la sintaxi i la semàntica exactes de try i catch, què es protegeix i què se salta quan salta una excepció, els mètodes de l'objecte capturat, la regla d'ordre obligatòria quan hi ha diversos catch —de la subclasse a la superclasse, amb l'error de compilació que dona si la inverteixes—, el multi-catch amb | de Java 7 i les seves regles, l'abast de les variables declarades dins del try, i les quatre coses sensates que es poden fer dins d'un catch: recuperar-se amb un valor per defecte, reintentar, traduir a una altra excepció o registrar i rellançar. Amb la demostració dels antipatrons i del cost real de llançar una excepció enfront d'un simple if. I amb la primera victòria tangible del mòdul: el menú interactiu de BiblioTech deixarà de morir-se quan algú escrigui "dotze" on s'esperava un número.