Antwoord.

Geschiedenis van de vraag

In Go wordt een pragmatische benadering van resource management aangenomen. In plaats van try-finally, dat bekend is uit andere talen, is er defer: een ingebouwd mechanisme dat een "uitgestelde" functie registreert en uitvoert wanneer je de scope verlaat. Dit hulpmiddel wordt vaak gebruikt voor de automatische vrijgave van bronnen (bestanden, netwerkverbindingen).

Probleem

Als je vergeet om Close aan te roepen bij een bestand of verbinding, kan er een resource-lek of blokkade optreden — dit is cruciaal in server- en bestandsapplicaties. De uitgestelde aanroep met defer garandeert dat de afsluitfunctie wordt aangeroepen, zelfs bij een fout of panic. Er zijn echter speciale gevallen waarin verkeerd gebruik van defer leidt tot fouten: het aanroepen van defer in een lus, het doorgeven van een onjuist object of werken met een groot aantal defers kan leiden tot overhead.

Oplossing

Roep altijd defer f.Close() aan direct na het succesvol openen van een bron, om vergeten sluitingen te voorkomen. Gebruik defer niet in nauwe lussen voor snelheid en geheugenbesparing als er veel bestanden worden geopend. Probeer het openen van bestanden/bronnen in een functie te wrappen om de scope te minimaliseren.

Voorbeeld van code:

file, err := os.Open("data.txt")
if err != nil {
    log.Fatal(err)
}
defer file.Close() // gegarandeerd sluiten
// ... werken met bestand

Belangrijke kenmerken:

• defer wordt altijd uitgevoerd, zelfs bij panic, maar na named return
• de volgorde van aanroepen van defer is strikt LIFO
• niet efficiënt in tight loops met grote allocaties

Vragen met een valstrik.

Wanneer wordt defer uitgevoerd en wanneer worden zijn parameters berekend?

De parameters van de functie in defer worden onmiddellijk bij de declaratie van defer berekend, niet bij de uitvoering van defer.

Voorbeeld van code:

func main() {
    a := 1
    defer fmt.Println(a) // onthoudt 1
    a = 42
}
// geeft 1 weer

Kan defer leiden tot geheugenlekken of vertragingen?

Ja, als je defer in een lus gebruikt, waar veel bestanden of objecten worden geopend, wordt elke defer opgeslagen in de stack van uitgestelde aanroepen, die pas wordt geleegd bij het verlaten van de functie, wat leidt tot onnodige geheugen groei.

Voorbeeld van code:

for i := 0; i < 10000; i++ {
    f, _ := os.Open("file.txt")
    defer f.Close() // houdt alle 10000 bestanden open tot het einde van main
}

Wat gebeurt er als het aanroepen van f.Close() een fout retourneert en deze "verstopt" wordt?

De standaardpraktijk is om de fout bij het sluiten van bronnen te loggen. Als dit wordt genegeerd, kunnen we falen of gedeeltelijke opslag van bestanden missen, bijvoorbeeld bij het niet kunnen verwijderen van een tijdelijk bestand of bij netwerkfouten.

Typische fouten en anti-patronen

• defer wordt binnen een lus aangeroepen => resource leak
• fout van Close() wordt niet behandeld
• defer zonder overeenstemming met de levensduur van de bron

Voorbeeld uit het leven

Negatieve case

In een lus voor bestandverwerking plaatst de ontwikkelaar defer f.Close() voor elk bestand. Hierdoor zijn er tegelijkertijd tienduizenden bestanden open, vertraagt de uitvoering van het programma, en raken de file descriptors op.

Voordelen:

• Zeer eenvoudige notatie

Nadelen:

• Ongeregelde groei van bronnen, mogelijke panic system (too many open files)

Positieve case

In de lus wordt de verwerking van elk bestand in een aparte functie gedaan, waar defer f.Close() alleen één keer wordt aangeroepen per verwerking en onmiddellijk de bron vrijgeeft.

Voordelen:

• Bronnen worden altijd op tijd vrijgegeven
• Geen verlies van prestaties

Nadelen:

• Functionele opsplitsing van code, vereist een goede structuur