M

MLOG

Italiano

Padroneggia la nuova Gestione Esplicita delle Risorse di JavaScript con `using` e `await using`. Impara ad automatizzare la pulizia, prevenire perdite di risorse e scrivere codice più pulito e robusto.

Il Nuovo Superpotere di JavaScript: Un'Analisi Approfondita della Gestione Esplicita delle Risorse

Nel dinamico mondo dello sviluppo software, la gestione efficace delle risorse è un pilastro fondamentale per costruire applicazioni robuste, affidabili e performanti. Per decenni, gli sviluppatori JavaScript si sono affidati a pattern manuali come try...catch...finally per garantire che le risorse critiche, come handle di file, connessioni di rete o sessioni di database, venissero rilasciate correttamente. Sebbene funzionale, questo approccio è spesso verboso, soggetto a errori e può diventare rapidamente ingestibile, un pattern a volte definito "piramide della dannazione" in scenari complessi.

Entra in scena un cambio di paradigma per il linguaggio: la Gestione Esplicita delle Risorse (ERM). Finalizzata nello standard ECMAScript 2024 (ES2024), questa potente funzionalità, ispirata a costrutti simili in linguaggi come C#, Python e Java, introduce un modo dichiarativo e automatizzato per gestire la pulizia delle risorse. Sfruttando le nuove parole chiave using e await using, JavaScript offre ora una soluzione molto più elegante e sicura a una sfida di programmazione senza tempo.

Questa guida completa vi accompagnerà in un viaggio attraverso la Gestione Esplicita delle Risorse di JavaScript. Esploreremo i problemi che risolve, analizzeremo i suoi concetti fondamentali, esamineremo esempi pratici e scopriremo pattern avanzati che vi permetteranno di scrivere codice più pulito e resiliente, indipendentemente da dove stiate sviluppando nel mondo.

La Vecchia Guardia: Le Sfide della Pulizia Manuale delle Risorse

Prima di poter apprezzare l'eleganza del nuovo sistema, dobbiamo prima comprendere i punti dolenti di quello vecchio. Il pattern classico per la gestione delle risorse in JavaScript è il blocco try...finally.

La logica è semplice: si acquisisce una risorsa nel blocco try e la si rilascia nel blocco finally. Il blocco finally garantisce l'esecuzione, sia che il codice nel blocco try abbia successo, fallisca o termini prematuramente.

Consideriamo uno scenario comune lato server: aprire un file, scriverci dei dati e poi assicurarsi che il file venga chiuso.

Esempio: Una Semplice Operazione su File con try...finally


const fs = require('fs/promises');

async function processFile(filePath, data) {
  let fileHandle;
  try {
    console.log('Apertura del file in corso...');
    fileHandle = await fs.open(filePath, 'w');
    console.log('Scrittura sul file...');
    await fileHandle.write(data);
    console.log('Dati scritti con successo.');
  } catch (error) {
    console.error('Si è verificato un errore durante l'elaborazione del file:', error);
  } finally {
    if (fileHandle) {
      console.log('Chiusura del file in corso...');
      await fileHandle.close();
    }
  }
}

Questo codice funziona, ma rivela diverse debolezze:

Ora, immaginate di gestire molteplici risorse, come una connessione a un database e un handle di file. Il codice diventa rapidamente un groviglio annidato:


async function logQueryResultToFile(query, filePath) {
  let dbConnection;
  try {
    dbConnection = await getDbConnection();
    const result = await dbConnection.query(query);

    let fileHandle;
    try {
      fileHandle = await fs.open(filePath, 'w');
      await fileHandle.write(JSON.stringify(result));
    } finally {
      if (fileHandle) {
        await fileHandle.close();
      }
    }
  } finally {
    if (dbConnection) {
      await dbConnection.release();
    }
  }
}

Questo annidamento è difficile da mantenere e scalare. È un chiaro segnale che è necessaria un'astrazione migliore. Questo è precisamente il problema che la Gestione Esplicita delle Risorse è stata progettata per risolvere.

Un Cambio di Paradigma: I Principi della Gestione Esplicita delle Risorse

La Gestione Esplicita delle Risorse (ERM) introduce un contratto tra un oggetto risorsa e il runtime di JavaScript. L'idea di base è semplice: un oggetto può dichiarare come deve essere pulito e il linguaggio fornisce una sintassi per eseguire automaticamente tale pulizia quando l'oggetto esce dal suo scope.

Questo si ottiene attraverso due componenti principali:

  1. Il Protocollo Disposable: Un modo standard per gli oggetti di definire la propria logica di pulizia utilizzando simboli speciali: Symbol.dispose per la pulizia sincrona e Symbol.asyncDispose per la pulizia asincrona.
  2. Le Dichiarazioni `using` e `await using`: Nuove parole chiave che legano una risorsa a uno scope di blocco. Quando si esce dal blocco, il metodo di pulizia della risorsa viene invocato automaticamente.

I Concetti Fondamentali: `Symbol.dispose` e `Symbol.asyncDispose`

Al centro dell'ERM ci sono due nuovi simboli ben noti. Un oggetto che ha un metodo con uno di questi simboli come chiave è considerato una "risorsa disposable".

Smaltimento Sincrono con `Symbol.dispose`

Il simbolo Symbol.dispose specifica un metodo di pulizia sincrono. È adatto per risorse la cui pulizia non richiede operazioni asincrone, come la chiusura sincrona di un handle di file o il rilascio di un lock in memoria.

Creiamo un wrapper per un file temporaneo che si pulisce da solo.


const fs = require('fs');
const path = require('path');

class TempFile {
  constructor(content) {
    this.path = path.join(__dirname, `temp_${Date.now()}.txt`);
    fs.writeFileSync(this.path, content);
    console.log(`File temporaneo creato: ${this.path}`);
  }

  // Questo è il metodo disposable sincrono
  [Symbol.dispose]() {
    console.log(`Smaltimento del file temporaneo: ${this.path}`);
    try {
      fs.unlinkSync(this.path);
      console.log('File eliminato con successo.');
    } catch (error) {
      console.error(`Impossibile eliminare il file: ${this.path}`, error);
      // È importante gestire gli errori anche all'interno di dispose!
    }
  }
}

Qualsiasi istanza di `TempFile` è ora una risorsa disposable. Ha un metodo identificato da `Symbol.dispose` che contiene la logica per eliminare il file dal disco.

Smaltimento Asincrono con `Symbol.asyncDispose`

Molte operazioni di pulizia moderne sono asincrone. La chiusura di una connessione a un database potrebbe comportare l'invio di un comando `QUIT` sulla rete, o un client di una coda di messaggi potrebbe dover svuotare il suo buffer in uscita. Per questi scenari, usiamo `Symbol.asyncDispose`.

Il metodo associato a `Symbol.asyncDispose` deve restituire una `Promise` (o essere una funzione `async`).

Modelliamo una finta connessione a un database che deve essere rilasciata in modo asincrono a un pool.


// Un pool di database fittizio
const mockDbPool = {
  getConnection: () => {
    console.log('Connessione al DB acquisita.');
    return new MockDbConnection();
  }
};

class MockDbConnection {
  query(sql) {
    console.log(`Esecuzione della query: ${sql}`);
    return Promise.resolve({ success: true, rows: [] });
  }

  // Questo è il metodo disposable asincrono
  async [Symbol.asyncDispose]() {
    console.log('Rilascio della connessione al DB nel pool...');
    // Simula un ritardo di rete per il rilascio della connessione
    await new Promise(resolve => setTimeout(resolve, 50));
    console.log('Connessione al DB rilasciata.');
  }
}

Ora, qualsiasi istanza di `MockDbConnection` è una risorsa disposable asincrona. Sa come rilasciarsi in modo asincrono quando non è più necessaria.

La Nuova Sintassi: `using` e `await using` in Azione

Con le nostre classi disposable definite, possiamo ora usare le nuove parole chiave per gestirle automaticamente. Queste parole chiave creano dichiarazioni con scope di blocco, proprio come `let` e `const`.

Pulizia Sincrona con `using`

La parola chiave `using` è usata per risorse che implementano `Symbol.dispose`. Quando l'esecuzione del codice lascia il blocco in cui è stata fatta la dichiarazione `using`, il metodo `[Symbol.dispose]()` viene chiamato automaticamente.

Usiamo la nostra classe `TempFile`:


function processDataWithTempFile() {
  console.log('Ingresso nel blocco...');
  using tempFile = new TempFile('Questi sono dati importanti.');

  // Qui puoi lavorare con tempFile
  const content = fs.readFileSync(tempFile.path, 'utf8');
  console.log(`Letto dal file temporaneo: "${content}"`);

  // Nessun codice di pulizia necessario qui!
  console.log('...altro lavoro in corso...');
} // <-- tempFile.[Symbol.dispose]() viene chiamato automaticamente proprio qui!

processDataWithTempFile();
console.log('Uscita dal blocco.');

L'output sarebbe:

Ingresso nel blocco...
File temporaneo creato: /path/to/temp_1678886400000.txt
Letto dal file temporaneo: "Questi sono dati importanti."
...altro lavoro in corso...
Smaltimento del file temporaneo: /path/to/temp_1678886400000.txt
File eliminato con successo.
Uscita dal blocco.

Guardate com'è pulito! L'intero ciclo di vita della risorsa è contenuto all'interno del blocco. La dichiariamo, la usiamo e ce ne dimentichiamo. Il linguaggio si occupa della pulizia. Questo è un enorme miglioramento in termini di leggibilità e sicurezza.

Gestione di Risorse Multiple

Si possono avere più dichiarazioni `using` nello stesso blocco. Verranno smaltite in ordine inverso rispetto alla loro creazione (un comportamento LIFO o "a stack").


{
  using resourceA = new MyDisposable('A'); // Creata per prima
  using resourceB = new MyDisposable('B'); // Creata per seconda
  console.log('Dentro al blocco, usando le risorse...');
} // resourceB viene smaltita per prima, poi resourceA

Pulizia Asincrona con `await using`

La parola chiave `await using` è la controparte asincrona di `using`. È usata per risorse che implementano `Symbol.asyncDispose`. Poiché la pulizia è asincrona, questa parola chiave può essere usata solo all'interno di una funzione `async` o al livello più alto di un modulo (se l'await di primo livello è supportato).

Usiamo la nostra classe `MockDbConnection`:


async function performDatabaseOperation() {
  console.log('Ingresso nella funzione asincrona...');
  await using db = mockDbPool.getConnection();

  await db.query('SELECT * FROM users');

  console.log('Operazione sul database completata.');
} // <-- await db.[Symbol.asyncDispose]() viene chiamato automaticamente qui!

(async () => {
  await performDatabaseOperation();
  console.log('La funzione asincrona è stata completata.');
})();

L'output dimostra la pulizia asincrona:

Ingresso nella funzione asincrona...
Connessione al DB acquisita.
Esecuzione della query: SELECT * FROM users
Operazione sul database completata.
Rilascio della connessione al DB nel pool...
(attende 50ms)
Connessione al DB rilasciata.
La funzione asincrona è stata completata.

Proprio come con `using`, la sintassi `await using` gestisce l'intero ciclo di vita, ma attende (`awaits`) correttamente il processo di pulizia asincrono. Può anche gestire risorse che sono solo disposable in modo sincrono: semplicemente non le attenderà.

Pattern Avanzati: `DisposableStack` e `AsyncDisposableStack`

A volte, il semplice scope di blocco di `using` non è abbastanza flessibile. E se si avesse bisogno di gestire un gruppo di risorse con un ciclo di vita non legato a un singolo blocco lessicale? O se si stesse integrando una libreria più vecchia che non produce oggetti con `Symbol.dispose`?

Per questi scenari, JavaScript fornisce due classi di supporto: `DisposableStack` e `AsyncDisposableStack`.

`DisposableStack`: Il Gestore di Pulizia Flessibile

Una `DisposableStack` è un oggetto che gestisce una collezione di operazioni di pulizia. È essa stessa una risorsa disposable, quindi si può gestire il suo intero ciclo di vita con un blocco `using`.

Ha diversi metodi utili:

Esempio: Gestione Condizionale delle Risorse

Immaginate una funzione che apre un file di log solo se una certa condizione è soddisfatta, ma volete che tutta la pulizia avvenga in un unico posto alla fine.


function processWithConditionalLogging(shouldLog) {
  using stack = new DisposableStack();

  const db = stack.use(getDbConnection()); // Usa sempre il DB

  if (shouldLog) {
    const logFileStream = fs.createWriteStream('app.log');
    // Rimanda la pulizia dello stream
    stack.defer(() => {
      console.log('Chiusura dello stream del file di log...');
      logFileStream.end();
    });
    db.logTo(logFileStream);
  }

  db.doWork();

} // <-- Lo stack viene smaltito, chiamando tutte le funzioni di pulizia registrate in ordine LIFO.

`AsyncDisposableStack`: Per il Mondo Asincrono

Come si potrebbe intuire, `AsyncDisposableStack` è la versione asincrona. Può gestire sia disposable sincroni che asincroni. Il suo metodo di pulizia principale è `.disposeAsync()`, che restituisce una `Promise` che si risolve quando tutte le operazioni di pulizia asincrone sono completate.

Esempio: Gestione di un Mix di Risorse

Creiamo un gestore di richieste per un server web che necessita di una connessione a un database (pulizia asincrona) e di un file temporaneo (pulizia sincrona).


async function handleRequest() {
  await using stack = new AsyncDisposableStack();

  // Gestisce una risorsa disposable asincrona
  const dbConnection = await stack.use(getAsyncDbConnection());

  // Gestisce una risorsa disposable sincrona
  const tempFile = stack.use(new TempFile('dati della richiesta'));

  // Adotta una risorsa da una vecchia API
  const legacyResource = getLegacyResource();
  stack.adopt(legacyResource, () => legacyResource.shutdown());

  console.log('Elaborazione della richiesta in corso...');
  await doWork(dbConnection, tempFile.path);

} // <-- viene chiamato stack.disposeAsync(). Attenderà correttamente la pulizia asincrona.

L'`AsyncDisposableStack` è uno strumento potente per orchestrare logiche complesse di setup e teardown in modo pulito e prevedibile.

Gestione Robusta degli Errori con `SuppressedError`

Uno dei miglioramenti più sottili ma significativi dell'ERM è il modo in cui gestisce gli errori. Cosa succede se viene lanciato un errore all'interno del blocco `using` e *un altro* errore viene lanciato durante il successivo smaltimento automatico?

Nel vecchio mondo del `try...finally`, l'errore del blocco `finally` di solito sovrascriveva o "sopprimeva" l'errore originale e più importante del blocco `try`. Questo rendeva spesso il debug incredibilmente difficile.

L'ERM risolve questo problema con un nuovo tipo di errore globale: `SuppressedError`. Se si verifica un errore durante lo smaltimento mentre un altro errore è già in propagazione, l'errore di smaltimento viene "soppresso". L'errore originale viene lanciato, ma ora ha una proprietà `suppressed` che contiene l'errore di smaltimento.


class FaultyResource {
  [Symbol.dispose]() {
    throw new Error('Errore durante lo smaltimento!');
  }
}

try {
  using resource = new FaultyResource();
  throw new Error('Errore durante l'operazione!');
} catch (e) {
  console.log(`Errore catturato: ${e.message}`); // Errore durante l'operazione!
  if (e.suppressed) {
    console.log(`Errore soppresso: ${e.suppressed.message}`); // Errore durante lo smaltimento!
    console.log(e instanceof SuppressedError); // false
    console.log(e.suppressed instanceof Error); // true
  }
}

Questo comportamento assicura che non si perda mai il contesto del fallimento originale, portando a sistemi molto più robusti e facili da debuggare.

Casi d'Uso Pratici nell'Ecosistema JavaScript

Le applicazioni della Gestione Esplicita delle Risorse sono vaste e rilevanti per gli sviluppatori di tutto il mondo, che lavorino sul back-end, sul front-end o nel testing.

Supporto di Browser e Runtime

Essendo una funzionalità moderna, è importante sapere dove si può utilizzare la Gestione Esplicita delle Risorse. A partire dalla fine del 2023 / inizio del 2024, il supporto è diffuso nelle ultime versioni dei principali ambienti JavaScript:

Per ambienti più datati, sarà necessario affidarsi a transpiler come Babel con gli appositi plugin per trasformare la sintassi `using` e fornire polyfill per i simboli e le classi stack necessari.

Conclusione: Una Nuova Era di Sicurezza e Chiarezza

La Gestione Esplicita delle Risorse di JavaScript è più di un semplice zucchero sintattico; è un miglioramento fondamentale del linguaggio che promuove sicurezza, chiarezza e manutenibilità. Automatizzando il processo noioso e soggetto a errori della pulizia delle risorse, libera gli sviluppatori di concentrarsi sulla loro logica di business principale.

I punti chiave da ricordare sono:

Quando iniziate nuovi progetti o refactorizzate codice esistente, considerate di adottare questo nuovo e potente pattern. Renderà il vostro JavaScript più pulito, le vostre applicazioni più affidabili e la vostra vita da sviluppatore un po' più semplice. È uno standard veramente globale per scrivere JavaScript moderno e professionale.