In Delphi 5, può mai sollevare un'eccezione?

Question

In Delphi 5, ho attualmente scritto il codice che chiama Free su più variabili in un blocco finally, ad es.

... 
finally 
    a.Free; 
    b.Free; 
    c.Free; 
end; 

Questo codice presuppone che Free può mai aumentare, dal momento che se, ad esempio, a.Free sollevato, la memoria per b e c sarebbe trapelato. Questa ipotesi è giustificata?

Answer 1

Il metodo Free non genera esplicitamente un'eccezione, ma chiama il distruttore virtuale Destroy che sicuramente potrebbe generare un'eccezione.

Quindi, se si vuole essere sicuri che tutti gli oggetti vengono distrutti, anche se uno dei distruttori solleva un'eccezione si finisce con codice come questo:

a := TMyObject.Create; 
try 
    b := TMyObject.Create; 
    try 
    ... 
    finally 
    b.Free; 
    end; 
finally 
    a.Free; 
end; 

Detto questo, dovrebbe essere un principio di progettazione che non si generano eccezioni in un distruttore. Quindi, a mio avviso, è perfettamente ragionevole considerare il punto di vista secondo cui se viene sollevata un'eccezione in distruttore, il tuo programma viene praticamente bloccato. La perdita di oggetti a quel punto non è qualcosa di cui preoccuparsi. Se il tuo distruttore ha sollevato un'eccezione, probabilmente stai già perdendo perché quel distruttore non è stato eseguito fino al completamento.

Quindi, a mio parere, può essere perfettamente ragionevole raggruppare alcune chiamate a Free e, naturalmente, si evita di nidificazione try/finally che è qualcosa vale la pena lottare per.

Se si desidera solo un try/finally poi ricordare a scrivere il codice come questo:

a := nil; 
b := nil; 
try 
    a := TMyObject.Create; 
    b := TMyObject.Create; 
    ... 
finally 
    b.Free; 
    a.Free; 
end; 

Nella mia base di codice Ho alcuni metodi di supporto che rendono questo più pulito.Poi il codice può assomigliare a questo:

InitialiseNil(a, b); 
try 
    a := TMyObject.Create; 
    b := TMyObject.Create; 
    ... 
finally 
    FreeAndNil(b, a); 
end; 

ho dato il mio FreeAndNil lo stesso nome della funzione in SysUtils che a prima vista può sembrare strano, ma è sicuro e benigna per farlo. Naturalmente questi aiutanti entrano in gioco quando hai anche più di due oggetti.

Answer 2

Dipende da ciò che accade nel distruttore.

Answer 3

Naturalmente FREE può emettere eccezioni, quindi sì, si perde memoria nel codice se A.FREE emette un'eccezione, B.FREE e C.FREE non verranno chiamati.

La domanda è: vuoi gestire le eccezioni o lasciarle accadere? Dipenderà da cosa sarà il tuo codice, altri sviluppatori lo useranno (per esempio). Per evitare perdite di memoria, è necessario nidificare le sezioni try..finally;

a:=tobject.create; 
try 
    b:=tobject.create; 
    try 
    c:=tobject.create; 

    ... 

    finally 
    c.free; 
    end; 
finally 
    b.free; 
end; 
a.free; 

Ordinamento. È una domanda su cosa sta facendo il tuo codice in realtà se dovessi anche racchiudere il A.FREE in una sezione try..finally anche se penso che probabilmente dovresti.

Answer 4

se il vostro a.free genera un'eccezione, a (a seconda di quanto il distruttore si è liberato dai campi dell'oggetto a), gli oggetti b e c avranno perdite perché l'esecuzione sarà interrotta. Ad ogni modo, qualcosa è sbagliato nel tuo distruttore, se solleva un errore. quindi, dovresti proteggere il codice con try..finally blocks, ma IMHO dovresti verificare che i distruttori non ti diano errori di circostanza.

Answer 5

Ci potrebbero essere 2 cose che possono causare SomeObj.Free a sollevare un'eccezione:

1. un'eccezione non gestita in distruttore della SomeObj istanza della classe o il suo antenato.
2. Riferimento di classe non valido a causa della variabile non inizializzata SomeObj.

Nel tuo caso, se a.Free solleva un'eccezione per uno dei motivi di cui sopra, ci sarebbe stata una perdita di memoria per oggetto b e c e magari un po 'di perdite all'interno oggetto a a causa di un'eccezione non gestita in distruttore.