El mòdul 6 va acabar amb una promesa i una mancança. La mancança: res no es guarda en sortir. Sis mòduls de feina —el catàleg, els préstecs, les multes, les reserves, l'historial— viuen íntegrament a la memòria del procés, i quan el procés acaba, la memòria s'allibera i tot desapareix. No hi ha res per recuperar. La promesa: que aquest mòdul ho resol.

Comencem per la meitat més senzilla de la persistència, que és llegir. Llegir és més senzill que escriure per una raó pràctica: si t'equivoques llegint, no destrueixes res. Si t'equivoques escrivint, pots perdre un fitxer sencer, i això és exactament el que li passarà a algú a la lliçó següent si no llegeix la taula del paràmetre append.

Aquesta lliçó cobreix el model mental complet de què és un fitxer, com es localitza i com se'n llegeix text amb les dues API clàssiques —FileReader i Scanner—, més el detall que provoca més incidències reals de tot el mòdul: la codificació de caràcters. En acabar, BiblioTech arrencarà llegint el seu catàleg d'un fitxer de text, i si aquest fitxer no existeix, arrencarà igualment amb el catàleg buit i deixant-ne constància al registre, aplicant la degradació elegant que ja saps dissenyar.

Tot el que s'obri en aquesta lliçó es tanca amb try-with-resources. És la construcció de 06-06 i es dona per completament coneguda: ordre de tancament invers, excepcions suprimides, close() idempotent. No es torna a explicar; es fa servir sempre.

1. Per què un programa necessita persistència
2. Què és un fitxer: bytes al disc davant d'objectes en memòria
3. El recorregut d'una dada des de l'aplicació fins al disc
4. Camins absoluts i relatius, i el directori de treball
5. Separadors de camí i portabilitat
6. La classe File: l'API heretada que encara et trobaràs
7. Lectura amb FileReader: caràcter a caràcter
8. Lectura amb Scanner sobre un fitxer
9. useDelimiter i l'anàlisi còmoda
10. Codificació de caràcters: UTF-8 i el desastre dels accents
11. FileNotFoundException davant d'IOException
12. Degradació elegant: BiblioTech arrenca sense catàleg
13. Fitxers grans i per què no llegir-ho tot en memòria
14. Errors Comuns i Consells
15. Exercicis

La memòria d'un procés és volàtil: existeix mentre el procés existeix. Quan main retorna, quan l'usuari tanca la finestra o quan el sistema operatiu mata el procés, la JVM allibera la seva memòria i tot el que hi havia deixa d'existir. No hi ha res per recuperar.

Això no és un defecte de Java: és la naturalesa de la RAM. Un programa que només treballa en memòria és un programa sense memòria a llarg termini, i això el desqualifica per a gairebé qualsevol ús real:

Fixa't en l'última fila de la columna esquerra aplicada a BiblioTech: si l'aplicació cau amb vint préstecs actius, aquests vint préstecs no van existir mai. La biblioteca real continuarà tenint vint llibres fora del prestatge, però el sistema dirà que estan tots disponibles. El sistema i el món deixen de coincidir, que és la pitjor cosa que li pot passar a un sistema de gestió.

Persistir significa escriure l'estat en un mitjà que sobreviu al procés. En aquest mòdul aquest mitjà és el sistema de fitxers. En un sistema professional gran acostuma a ser una base de dades —ho veuràs amb Hibernate a 11-03—, però una base de dades és, per sota, fitxers amb molta enginyeria a sobre. Tot comença aquí.

Aquesta és la idea que cal interioritzar abans d'escriure una línia de codi:

Un fitxer és una seqüència de bytes amb un nom. Res més. No té tipus, no té objectes, no té camps. Només bytes numerats del 0 endavant.

Compara els dos mons:

Quan tens en memòria un Llibre amb títol "Java Eficaç", autor "Bloch" i ISBN 978-0000000001, l'objecte ocupa una zona de memòria amb tres referències a tres objectes String. Al disc no pots desar referències: una adreça de memòria no significa res demà ni en una altra màquina. Has de serialitzar: convertir aquesta estructura en una seqüència de bytes que puguis tornar a interpretar després. La forma més simple de fer-ho és escriure text:

Aquesta línia és una decisió de disseny completa. Has triat: un material per línia, camps separats per ;, ordre fix de camps, true/false per a la disponibilitat. Qualsevol programa que conegui aquesta convenció pot llegir-la. És exactament el que fa un fitxer CSV, i el formalitzaràs a 07-07.

L'alternativa és deixar que Java faci la conversió per tu, amb la serialització nativa de 07-05, que produeix bytes il·legibles però conserva l'estructura completa d'objectes. Cada opció té el seu preu, i el veuràs.

Un matís important sobre el vocabulari: es parla de fitxers de text i fitxers binaris, però aquesta distinció no existeix al disc. Tots els fitxers són binaris. Un "fitxer de text" és simplement un fitxer els bytes del qual, interpretats amb una determinada codificació, produeixen caràcters llegibles. Si obres un .jpg amb un editor de text, hi veuràs brossa: no perquè el fitxer sigui diferent, sinó perquè hi estàs aplicant la interpretació equivocada. Hi tornarem a l'apartat 10 i, a fons, a 07-03.

Entre el teu String i el plat del disc hi ha més capes de les que sembla. Conèixer-les explica per què l'E/S és lenta, per què existeix la memòria intermèdia i per què un close() pot fallar.

Els punts que importen d'aquest recorregut:

• La frontera cara és la crida al sistema (requadre taronja). Cada read obliga a passar del codi de la teva aplicació al nucli del sistema operatiu i tornar. Aquest canvi de context costa ordres de magnitud més que executar unes quantes instruccions en memòria. Si fas una crida al sistema per cada caràcter, el cost és demolidor: és exactament el que passa amb FileReader sense memòria intermèdia, i ho mesuraràs a l'apartat 7.
• La descodificació és un pas real (requadre blau clar del mig). Els bytes que arriben del disc no són caràcters. Algú ha de decidir quin byte o grup de bytes forma quin caràcter, i aquest algú és el charset. Si ningú no l'especifica, se'n fa servir un per defecte, i aquí comencen els problemes de l'apartat 10.
• El sistema operatiu ja té la seva pròpia memòria cau (la page cache). Per això llegir dues vegades el mateix fitxer petit és molt més ràpid la segona vegada: la segona no arriba al disc. Això també explica per què mesurar el rendiment d'E/S és traïdor.
• Escriure no significa "és al disc". Quan escrius, la dada passa a memòries intermèdies. Fins que no es buiden, un tall de corrent la perd. És el tema central de 07-02.

Queda't amb la regla que governa tot el mòdul: com menys crides al sistema, millor. Tot el disseny de l'E/S de Java —les memòries intermèdies, els blocs, transferTo— existeix per reduir aquest nombre.

Per llegir un fitxer cal localitzar-lo, i aquí apareix el primer entrebanc clàssic: "a mi em funcionava i al servidor diu que no troba el fitxer".

Un camí absolut parteix de l'arrel del sistema de fitxers i és autosuficient:

Un camí relatiu no parteix de l'arrel, sinó del directori de treball actual del procés:

La pregunta clau és: relatiu a què? I la resposta és la que sorprèn tothom: relatiu al directori des del qual es va llançar la JVM, no al directori on hi ha el .class ni al del projecte. Aquest directori és a la propietat de sistema user.dir:

Executa aquest programa des de dos llocs diferents i veuràs el problema en directe:

El mateix programa, el mateix fitxer al disc, dos resultats diferents. Això és el que passa quan funciona a l'IDE (que llança des de l'arrel del projecte) i falla en executar-lo amb un script (que llança des d'un altre lloc).

Com es tracta això professionalment:

I un consell que estalvia molt de temps: quan un fitxer "no existeix", imprimeix sempre el camí absolut, mai el que t'han passat. El missatge No es troba 'dades/cataleg.txt' no et diu res; No es troba '/home/marta/bibliotech/target/classes/dades/cataleg.txt' et resol el problema en tres segons. Aquesta és una aplicació directa de la lliçó 06-04: una excepció ha de transportar les dades que qui la llegeix necessita per decidir.

Windows fa servir \ com a separador de directoris; Linux, macOS i pràcticament tota la resta fan servir /. Java ofereix dues constants per no fixar-ho al codi:

Distingeix les dues constants, que es confonen sovint:

Ara bé, la bona notícia pràctica: Windows accepta / a gairebé totes les API de Java. new File("dades/cataleg.txt") funciona a Windows. Per això, a la pràctica:

• Per a literals curts al codi, escriu / i no t'ho compliquis: és llegible i funciona a tot arreu.
• Per compondre camins a partir de trossos, no concatenis cadenes: fes servir new File(pare, fill) o, encara millor, Path.resolve() de NIO.2, que veuràs a 07-06 i és la forma moderna i correcta.
• No escriguis mai "C:\\dades\\cataleg.txt" al codi. A més de no ser portable, aquesta doble barra invertida és una font inesgotable d'errades.

java.io.File és de Java 1.0. Representa un camí, no un fitxer obert: pots crear un File que apunti a una cosa inexistent sense que passi res.

Els mètodes que més es fan servir:

I aquí hi ha el gran defecte d'aquesta API, el que en va motivar la substitució:

Aquest false mut és exactament l'antipatró que el mòdul 6 va dedicar set lliçons a eradicar: comunicar una fallada sense dir quina. L'API moderna, NIO.2 (java.nio.file.Path i Files, lliçó 07-06), llança excepcions específiques —NoSuchFileException, AccessDeniedException, DirectoryNotEmptyException— en lloc de retornar boolean.

Aleshores, per què aprenem File? Per tres motius molt pràctics. Primer, perquè hi ha milions de línies de codi escrites amb ella i les llegiràs. Segon, perquè moltes API encara demanen un File com a paràmetre. I tercer, perquè la conversió entre tots dos mons és trivial: file.toPath() i path.toFile(). Fes servir NIO.2 al codi nou; entén File per llegir l'antic.

FileReader és la classe més elemental per llegir text d'un fitxer. El seu mètode fonamental és read(), i el seu contracte té un detall que cal entendre bé:

Retorna un int, no un char. Per què? Perquè necessita un valor extra que no sigui un caràcter vàlid per assenyalar el final de fitxer, i aquest valor és -1. Els caràcters vàlids van de 0 a 65535; -1 no col·lisiona amb cap. Si el mètode retornés char, no hi hauria manera de distingir "he llegit el caràcter 0" de "s'ha acabat".

Desglossem el bucle, perquè la seva forma és idiomàtica i la veuràs pertot arreu:

1. lector.read() llegeix el caràcter següent i avança la posició.
2. codi = ... desa el resultat a la variable. En Java, una assignació és una expressió el valor de la qual és l'assignat; per això pot fer-se servir dins de la condició.
3. Els parèntesis externs són obligatoris: sense ells, codi = lector.read() != -1 intentaria assignar un boolean a un int i no compilaria.
4. La comparació decideix si continuar.

I ara, el problema. Aquest codi és correcte però lent, i convé entendre exactament quant:

Amb un fitxer de 5 MB, en una màquina d'escriptori corrent, els ordres de magnitud són aquests (xifres il·lustratives, no un mesurament formal):

Dos ordres de magnitud de diferència, i la causa és exactament la de l'apartat 3: cada read() sense memòria intermèdia es tradueix en una petició al sistema operatiu. Cinc milions de creuaments de frontera per llegir cinc megabytes.

La solució intermèdia, sense sortir encara de FileReader, és llegir per blocs amb la sobrecàrrega que accepta un array:

Dos detalls crítics d'aquest codi, i tots dos són font d'errors reals:

• read(char[]) retorna el nombre d'elements llegits, que pot ser menor que la mida de l'array encara que el fitxer no s'hagi acabat. No suposis mai que omple la memòria intermèdia.
• Cal fer servir append(bloc, 0, llegits), no append(bloc). Si fas servir la versió sense límits, a l'última volta afegiràs la brossa que va quedar a l'array de la volta anterior. És una fallada que només es manifesta al final del fitxer i amb contingut aparentment aleatori.

La forma definitiva de resoldre això —embolcallar el FileReader en un BufferedReader que gestiona el bloc per tu— és el tema de 07-04. Aquí queda clar el perquè; allà en veuràs el com amb tot el detall.

Ja coneixes Scanner del mòdul 1, llegint de System.in. La mateixa classe llegeix d'un fitxer: només canvia el que li passes al constructor.

La parella hasNextLine() / nextLine() és el patró canònic i mereix un avís:

Comprova sempre amb hasNextLine() abans de cridar nextLine(). Si crides nextLine() sense que quedin línies, llança NoSuchElementException, que és no comprovada: el compilador no t'avisa i peta en execució. És el mateix contracte d'Iterator que vas veure a 05-02.

Scanner no es queda en línies: sap analitzar tipus, i aquí hi ha la seva comoditat. Suposa aquest fitxer de préstecs de BiblioTech:

Es llegeix així, camp a camp, sense partir cadenes a mà:

Compte amb dos comportaments de Scanner que causen sorpreses:

• nextDouble() depèn de la configuració regional. Amb l'idioma català, el separador decimal és la coma, així que 0.25 pot fallar amb InputMismatchException mentre que 0,25 funciona. És una fallada que apareix només en algunes màquines i desconcerta. La solució és fixar la configuració explícitament:

Aquest mateix problema, aplicat als fitxers CSV que s'obren en un full de càlcul català, reapareix a 07-07.

• nextInt() no consumeix el salt de línia. Si barreges nextInt() amb nextLine(), el nextLine() retornarà la cadena buida que queda fins al final de la línia actual. És el parany que ja vas veure amb la consola al mòdul 1, i aquí és idèntic.

Comparació honesta de les dues API vistes fins ara:

Per a un fitxer de configuració de vint línies, Scanner és còmode i la seva lentitud és irrellevant. Per al fitxer de catàleg de deu mil materials, la resposta correcta és BufferedReader, i la veuràs a 07-04.

Per defecte, Scanner separa per espais en blanc. useDelimiter canvia aquest criteri a qualsevol expressió regular, cosa que permet llegir fitxers amb separadors propis sense partir cadenes a mà.

Amb aquest fitxer de catàleg:

Es llegeix així:

Delimitadors útils:

Aquest últim truc té la seva gràcia per a fitxers molt petits:

Funciona, però és un pedaç. Des de Java 11 existeix Files.readString(Path), que fa el mateix de forma explícita i correcta, i el veuràs a 07-06. Reconeix el truc quan el llegeixis en codi aliè; no l'escriguis tu.

I un advertiment que cal donar ja, tot i que es desenvolupi a 07-07: partir un CSV per ; o per , és correcte només mentre cap camp no contingui el separador. Tan bon punt aparegui un títol com "Java: el llenguatge, la màquina i l'ecosistema" dins de cometes, aquest codi produeix camps mal alineats en silenci. La lliçó 07-07 implementa un lector CSV que sí que ho fa bé.

Aquest apartat és el més important de la lliçó. La majoria de les fallades d'E/S que veuràs a la teva carrera professional no són fallades de lògica: són fallades de codificació.

Un fitxer conté bytes. Un String conté caràcters. Convertir d'un a l'altre requereix una taula de correspondències, i aquesta taula és el charset o codificació.

• ASCII (1963): 128 caràcters, un byte cadascun. Sense ç, sense à, sense €.
• ISO-8859-1 (Latin-1): 256 caràcters, un byte cadascun. Té ç i vocals accentuades. No té € ni res que no sigui europeu occidental.
• Windows-1252: variant de l'anterior, la de Windows a Europa occidental. Gairebé igual però no exactament, cosa que genera fallades subtils.
• UTF-8 (1993): cobreix tot Unicode amb longitud variable d'1 a 4 bytes. ASCII n'és un subconjunt exacte. És l'estàndard de facto del web i de l'intercanvi de dades.

Quant ocupa cada caràcter en UTF-8:

Conseqüència directa que sorprèn molta gent: en UTF-8, el nombre de caràcters d'un text no és el nombre de bytes del fitxer. "Eficaç" són 6 caràcters i 7 bytes. Per això File.length() (bytes) no et diu quants caràcters hi ha.

Escrius "Préstec vençut" en UTF-8 i ho llegeixes com a ISO-8859-1. Els dos bytes de la ç (0xC3 0xA7) s'interpreten com dos caràcters independents:

A l'inrevés, escrius en ISO-8859-1 i llegeixes en UTF-8. El byte 0xE7 de la ç no forma una seqüència UTF-8 vàlida, i el descodificador el substitueix pel caràcter de reemplaçament:

Aquest ç i aquest � són els dos símptomes que cal aprendre a reconèixer a l'instant. Quan els vegis, no busquis la fallada a la teva lògica: és codificació.

I hi ha una cosa pitjor que la lletjor. Fixa't en aquest cas:

Les dades continuen malament després de llegir-les. Es desaran malament, es compararan malament i es mostraran malament. La corrupció es propaga.

Fins a Java 17 inclòs, quan no especifiques charset, FileReader i FileWriter fan servir la codificació per defecte de la plataforma, que depèn del sistema operatiu i de la configuració regional:

Això significa que el mateix programa llegint el mateix fitxer produeix resultats diferents en màquines diferents. És la causa del clàssic "al meu portàtil es veu bé i al servidor surt amb interrogants".

Java 18 (JEP 400) va canviar el valor per defecte de file.encoding a UTF-8 a totes les plataformes, cosa que és una gran millora. Però:

• Si treballes amb Java 17 —la versió de referència d'aquest curs i la més usada en producció— continues tenint el comportament antic.
• Encara que el teu projecte sigui Java 21, el codi que especifica el charset és autoexplicatiu i no depèn d'una propietat que algú pugui canviar amb -Dfile.encoding.

Regla professional, sense excepcions: especifica sempre el charset explícitament en tota operació de text. No costa res i elimina una categoria sencera de fallades.

Des de Java 11, FileReader accepta un Charset al constructor:

En versions anteriors —i continua sent la forma més general, la que veuràs a 07-03— es fa servir el pont InputStreamReader:

I Scanner també l'accepta:

Les constants disponibles a java.nio.charset.StandardCharsets, garantides a tota JVM:

Fes servir les constants, no les cadenes. new FileReader(cami, StandardCharsets.UTF_8) no pot fallar; la versió que accepta el nom com a cadena llança UnsupportedEncodingException si escrius "UTF8", "utf-8 " amb un espai o qualsevol altra errada. És un error de compilació convertit en error d'execució sense cap avantatge.

L'E/S és el territori natural de les excepcions comprovades del mòdul 6, i per un motiu que ara resulta evident: el fitxer és del món exterior. Pot no existir, pot haver canviat de permisos, el disc es pot omplir, algú pot desconnectar la unitat de xarxa. Res d'això no és una fallada del teu programa, i tot és previsible.

La jerarquia rellevant:

Què significa cadascuna a la pràctica:

Nota enganyosa sobre el nom: FileNotFoundException no significa només "no existeix". També es llança si el camí apunta a un directori o si el fitxer existeix però no tens permís de lectura. Per això el missatge del sistema operatiu és tan valuós i no l'has de descartar mai.

L'ordre dels catch segueix la regla de 06-02, del que és específic al que és general:

Ho ajuntarem tot amb la primera peça real del mòdul. CarregadorCataleg llegeix un fitxer de text i construeix materials, i —això és l'important— si el fitxer no existeix, l'aplicació arrenca igualment amb el catàleg buit.

Aquest és exactament el criteri de 06-07 per distingir el que és recuperable del que és irrecuperable: degrada quan el servei reduït continuï sent correcte. Una biblioteca sense materials és una biblioteca buida, que és un estat perfectament vàlid i en el qual es poden donar d'alta materials. No hi ha res d'incorrecte. Molt diferent seria arrencar sense conèixer la tarifa de les multes: allà no es pot degradar, perquè cobraríem imports falsos.

El format del fitxer:

I el carregador:

I l'arrencada de l'aplicació queda així:

Les tres decisions de disseny que convé assenyalar:

1. El camí arriba per argument, amb un valor per defecte. És l'estratègia recomanada de l'apartat 4: qui executa decideix on són les dades.
2. carregar() no retorna mai null. Retorna un Cataleg buit si no hi ha fitxer. És la regla que 06-07 va establir: el null no és una forma de comunicar res.
3. Una línia dolenta no avorta el fitxer. Es descarta, es compta i es registra. Que un catàleg de deu mil línies no es carregui perquè la línia 4 200 té un any mal escrit seria una política pèssima. Això és l'"objecte resultat" de 06-07 aplicat a la importació, i a 07-04 es convertirà en un informe complet.

Tanquem amb un advertiment de dimensionament. És temptador escriure això:

I per a un fitxer de configuració de 2 KB és perfectament raonable. Però per a l'històric de préstecs de tres anys, no:

Per què el factor de dos: internament un String de Java 9 endavant desa un byte per caràcter quan tot el text és Latin-1 i dos bytes per caràcter tan bon punt apareix un caràcter fora d'aquest rang. Un sol emoji o un caràcter ciríl·lic en un fitxer de 2 GB duplica la memòria de l'String complet. I a més necessites el StringBuilder intermedi mentre el construeixes, així que al pic arribes a tenir el contingut dues vegades.

Un OutOfMemoryError és un Error, no una Exception: no es captura, no es recupera i tomba el procés, amb la salvetat de la frontera de main que vas veure a 06-07.

L'alternativa correcta és processar en flux (streaming): llegir una línia, processar-la, oblidar-la, llegir la següent. La memòria usada és la d'una línia, no la del fitxer, i el consum és constant encara que el fitxer tingui 50 GB:

La regla pràctica:

Carrega el fitxer sencer en memòria només si en coneixes la mida màxima i és petita. Configuració, plantilles, fitxers de pocs KB: endavant. Dades, registres, exportacions, qualsevol cosa que creixi amb l'ús: processa en flux.

Aquesta és exactament la raó de ser de BufferedReader, que és la lliçó 07-04.

• Fer servir camins relatius i no saber respecte a què. El clàssic "funciona a l'IDE i falla en producció". Imprimeix System.getProperty("user.dir") tan bon punt tinguis dubtes i passa els camins per paràmetre.
• Informar de l'error amb el camí relatiu. No es troba 'dades/cataleg.txt' no serveix de res. Registra sempre getAbsolutePath().
• No especificar el charset. L'error més car del mòdul a llarg termini, perquè no falla: corromp en silenci. StandardCharsets.UTF_8, sempre, en tota operació de text.
• Confondre ç amb ?. ç significa que vas escriure UTF-8 i vas llegir Latin-1. ? o � significa el contrari. Reconèixer el símptoma t'estalvia mitja hora cada vegada.
• Fer servir cadenes en lloc de constants de charset. "UTF8" compila i peta en execució. StandardCharsets.UTF_8 no es pot escriure malament.
• Declarar char c = lector.read(). No compila, i per un bon motiu: cal el -1 per al final de fitxer, que no cap en un char.
• Oblidar els parèntesis a while ((c = lector.read()) != -1). Sense ells no compila. Amb ells, és el bucle idiomàtic que veuràs sempre.
• Fer servir append(bloc) en lloc d'append(bloc, 0, llegits). Afegeix brossa de la volta anterior a l'última lectura. Falla només al final del fitxer, que és el que ho fa difícil de diagnosticar.
• Cridar nextLine() sense comprovar hasNextLine(). NoSuchElementException, no comprovada, en execució.
• Barrejar nextInt() i nextLine() sense consumir el salt de línia. El mateix parany del mòdul 1, idèntic sobre fitxers.
• Confiar en nextDouble() sense fixar el Locale. En una màquina amb configuració catalana, 0.25 pot fallar. sc.useLocale(Locale.ROOT).
• Llegir caràcter a caràcter un fitxer gran. Correcte i cent vegades més lent. Blocs o BufferedReader (07-04).
• Carregar en un String un fitxer de mida desconeguda. OutOfMemoryError, que no es captura. Processa en flux.
• Interpretar length() == 0 com a "no existeix". Un fitxer buit dona el mateix. Fes servir exists().
• Ignorar que listFiles() pot retornar null. NullPointerException al for. NIO.2 ho resol (07-06).
• Consell: escriu una única classe que sàpiga llegir cada tipus de fitxer. Si tens new FileReader(...) repartit per vint classes, canviar el charset o el format serà un rastreig. Concentra l'E/S a la capa que li correspon, com fa CarregadorCataleg.
• Consell: prova sempre amb un fitxer que contingui ç, à i €. Un fitxer de prova només amb ASCII t'ocultarà totes les fallades de codificació fins que arribi a producció.
• Consell: prova també amb el fitxer absent i amb el fitxer buit. Són els dos casos que més s'obliden i els dos que més passen, sobretot el primer dia de vida del sistema.

Escriu una classe DiagnosticCami amb un mètode public static void diagnosticar(String cami) que imprimeixi un informe complet i útil sobre un camí, pensat perquè algú hi pugui resoldre un problema:

1. El camí tal com s'ha donat i la seva forma absoluta.
2. El directori de treball actual.
3. Si existeix; i si no existeix, si existeix el seu directori pare (per distingir "falta el fitxer" de "el directori no és aquest").
4. Si existeix: si és fitxer o directori, si és llegible, la seva mida i el nombre de línies.
5. Un diagnòstic final en una frase amb la causa més probable.

Prova'l amb un camí correcte, un d'inexistent i un directori.

Escriu DetectorCodificacio amb un mètode public static void comparar(String cami) que llegeixi el mateix fitxer tres vegades —com a UTF-8, com a ISO-8859-1 i com a US-ASCII— i mostri les tres primeres línies de cada lectura, per veure l'efecte sobre els accents i les ce trencades.

Després, afegeix public static boolean semblaUtf8(String cami), que retorni true si el fitxer es descodifica sense cap caràcter de reemplaçament (\uFFFD) en llegir-lo com a UTF-8. Explica en un comentari per què aquesta comprovació detecta "això no és UTF-8" però no pot detectar "això és Latin-1 llegit com a UTF-8 a l'inrevés".

Prepara un fitxer de prova amb Préstec vençut, Refactorització i Reunió de març.

Amplia la idea de CarregadorCataleg als empleats. Donat un fitxer com aquest:

Escriu CarregadorEmpleats amb:

1. public ResultatCarrega carregar(), que retorni un objecte resultat (idea de 06-07) amb la llista d'empleats carregats i la llista d'errors, en lloc de llançar a la primera fallada.
2. Validació de cada línia: exactament 3 camps, identificador amb format E-NNN, nom no buit i nombre de préstecs entre 0 i Empleat.MAX_PRESTECS_SIMULTANIS.
3. Degradació si el fitxer no existeix: resultat buit amb un avís, sense excepció.
4. Charset explícit i try-with-resources.
5. Un main de demostració que imprimeixi l'informe amb printf.

Afegeix al fitxer de prova una línia amb dos camps, una amb un identificador X-999 i una amb 9 préstecs, per comprovar que les tres es descarten amb el seu motiu i les bones es carreguen.

Solució 1

El que ensenya aquest exercici: la diferència entre detectar una fallada i explicar-la. Els cinc casos de concloure corresponen a cinc causes diferents que l'API resumeix totes en un exists() a false. Distingir-les és el que converteix un missatge d'error en una solució. Fixa't també en el comentari sobre TOCTOU: entre comprovar exists() i obrir el fitxer pot passar qualsevol cosa, així que la comprovació prèvia no substitueix el catch.

Solució 2

Amb un fitxer de prova desat en UTF-8 que contingui Préstec vençut, Refactorització i Reunió de març, la sortida és:

La conclusió pràctica és la del comentari: la detecció de codificació és fonamentalment impossible en el cas general. Els editors de text l'endevinen amb heurístiques i de vegades s'equivoquen. Per això cap quantitat de perspicàcia al codi no substitueix la regla simple: especifica sempre el charset, en llegir i en escriure.

Solució 3

Amb aquest fitxer de prova:

La sortida és:

Les tres decisions que val la pena assenyalar:

1. L'objecte resultat en lloc d'una excepció per línia. Qui importa un fitxer vol veure tots els problemes de cop per corregir-los i tornar-ho a intentar, no descobrir-los d'un en un. És exactament el cas d'ús que 06-07 va plantejar per a l'objecte resultat.
2. split(SEPARADOR, -1). Sense aquest -1, split descarta els camps buits finals, així que E-001;; donaria 1 camp en lloc de 3 i el missatge d'error seria incorrecte. És un parany clàssic que reapareixerà a 07-07.
3. El fitxer absent no és un error de línia. Es marca a part, perquè són dues situacions diferents: "no hi ha dades" i "hi ha dades mal escrites". Confondre-les produeix informes inútils.

Has posat els fonaments de la persistència de BiblioTech.

Entens què és un fitxer de veritat: una seqüència de bytes amb un nom, sense tipus ni estructura, davant d'un objecte en memòria amb camps i referències. Saps que passar d'un a l'altre exigeix una decisió de format explícita —un material per línia, camps separats per ;— i que aquesta decisió és el germen del CSV de 07-07. I coneixes el recorregut complet de la dada fins al disc, amb la conclusió que governa tot el mòdul: la crida al sistema és l'operació cara, i tot el disseny de l'E/S existeix per reduir-ne el nombre.

Saps localitzar un fitxer: camins absoluts i relatius, el paper de user.dir com a origen dels relatius, i per què el mateix programa "no troba" el mateix fitxer segons des d'on es llanci. Tens les cinc estratègies professionals per no dependre d'això, amb la recomanació de passar el camí per paràmetre, i la regla de registrar sempre el camí absolut als missatges d'error. Coneixes File.separator davant de File.pathSeparator i per què és millor compondre camins que concatenar cadenes.

Coneixes java.io.File —exists, isFile, canRead, length, getAbsolutePath— i, sobretot, el defecte que la va condemnar: els boolean muts que diuen que alguna cosa ha fallat sense dir per què, exactament l'antipatró que el mòdul 6 va eradicar. Saps que 07-06 la substitueix per Path i Files, i que la conversió entre totes dues és un toPath().

Saps llegir amb FileReader caràcter a caràcter, amb l'int de retorn i el -1 de final de fitxer, i per què aquest bucle és dos ordres de magnitud més lent del que cal. Coneixes la lectura per blocs amb read(char[]) i els seus dos paranys: el valor de retorn que pot ser menor que l'array, i l'append(bloc, 0, llegits) que evita arrossegar brossa. I saps llegir amb Scanner sobre fitxer, amb hasNextLine/nextLine, l'anàlisi de tipus, useDelimiter amb expressions regulars, i les seves dues sorpreses: el Locale que canvia el separador decimal i el nextInt() que no consumeix el salt de línia.

I tens l'apartat que més incidències reals evita: la codificació. Saps què és UTF-8, per què ç ocupa dos bytes, què significa exactament veure ç i què significa veure �, per què la codificació per defecte de la plataforma és una bomba de rellotgeria entre màquines, què va canviar Java 18 i per què això no t'eximeix d'especificar-la. I saps que detectar la codificació és impossible en el cas general, cosa que converteix la regla en absoluta: StandardCharsets.UTF_8, explícit, sempre.

BiblioTech ja llegeix. CarregadorCataleg construeix el catàleg des d'un fitxer de text, descarta les línies mal formades comptant-les i registrant-les en lloc d'avortar la càrrega sencera, tradueix NumberFormatException i ReferenciaDuplicadaException a descarts amb context, i —el més important— degrada elegantment: si no hi ha fitxer de catàleg, arrenca amb el catàleg buit i un WARNING, perquè una biblioteca buida és un estat correcte. És la política d'errors de 06-07 aplicada a l'E/S des de la primera línia de codi.

Queda la meitat que falta, i és la que fa por. Llegir és segur; escriure destrueix. A la lliçó 07-02, Escriptura de fitxers, veuràs FileWriter i el paràmetre append que decideix entre afegir al final i esborrar el fitxer sencer, que és l'error més car de tot el mòdul; PrintWriter amb el printf que ja fas servir des del mòdul 1; la memòria intermèdia i el buidatge, i per què el que has escrit pot no ser al disc fins que tanquis; el patró d'escriptura atòmica —escriure a un temporal i reanomenar— que impedeix deixar un fitxer a mitges quan alguna cosa falla pel mig, germà directe de la compensació al finally que ja saps escriure; i el separador de línia del sistema, amb el motiu pel qual \n no sempre n'hi ha prou. En acabar-la, ExportadorCataleg deixarà de ser una classe que sap tancar-se però no escriure, i BiblioTech desarà per primera vegada el que ha fet.