Antwoord.

Perl is oorspronkelijk ontworpen als een scripts taal voor systeembeheer, dus het traditionele model voor foutafhandeling was eerder procedureel. Maar in de loop der tijd zijn er geavanceerdere technieken voor het omgaan met uitzonderingen en fouten in de taal gekomen.

Geschiedenis van de vraag

In de eerste versies van Perl werden fouten opgevangen via de geretourneerde waarden van functies en door de globale variabele $! te controleren, later kwamen er structuren zoals eval (dynamische vangst) en modulen zoals Try::Tiny voegden beknopte, veilige try-catch-patronen toe.

Probleem

Standaard Perl heeft geen ingebouwde try-catch-syntaxis. Fouten kunnen zich voordoen zowel in Perl-code als in externe aanroepen (bijvoorbeeld bij het openen van bestanden). Als fouten niet expliciet worden afgehandeld, kan het programma doorgaan met werken in een onvoorspelbare staat. Het is noodzakelijk om de techniek voor het opvangen van fouten zorgvuldig te selecteren, afhankelijk van de context, de complexiteit van de applicatie en de vereisten voor betrouwbaarheid.

Oplossing

Voor het opvangen van fouten in Perl wordt de functie eval gebruikt, waarbij potentiële gevaarlijke code in een blok wordt ingepakt en de inhoud van $@ na uitvoering wordt geanalyseerd.
Voor het genereren van eigen fouten wordt die gebruikt. Meer gerichte foutgeneratie en het opnieuw opwerpen van al beschreven uitzonderingen gebeurt via de Sinon-structuur.
Voor "menselijke" foutafhandeling is het handig om externe modules te gebruiken (bijvoorbeeld Try::Tiny).

Voorbeeldcode — foutafhandeling via Try::Tiny:

use Try::Tiny;

try {
    open my $fh, '<', 'file.txt' or die "Kan bestand niet openen: $!";
    while (<$fh>) {
        print $_;
    }
}
catch {
    warn "Er is een fout opgetreden: $_";
};

Belangrijke kenmerken:

Het foutmechanisme is asynchroon — fouten binnen eval en try/catch wijzigen de hoofd uitvoeringsstroom niet totdat ze expliciet worden afgehandeld.
Het opvangen van fouten is mogelijk op verschillende niveaus — low-level die/warn/return of high-level try/catch in modules.
Modulen helpen typische fouten met eval te vermijden, die verband houden met het overschrijven van $@ en scope-valstrikken.

Vragen met een val

In welk geval vangt een eval-blok geen systeemb fout?

Eval vangt niet altijd een fout als er binnenin een fatale exit in C-bibliotheken gebeurt (bijvoorbeeld SEGFAULT uit XS-code). Eval werkt alleen met fatale Perl-fouten, en niet met crashes van C-extensies.

Wat gebeurt er met de variabele $@ bij geneste eval-blokken?

Als binnen een eval een andere eval wordt aangeroepen, wordt de waarde van $@ overschreven bij exit. Daarom is het raadzaam om $@ in een aparte variabele op te slaan na elke eval, om de originele fout niet te verliezen.

Waarom verklaren hulpfuncties zoals Try::Tiny de variabele $@ lokaal binnen catch/try?

Omdat Perl $@ automatisch alleen leegt bij een succesvolle exit uit try (eval). Terugkeer bij fout, next, last kan er toe leiden dat $@ niet is geleegd, en er in de volgende code een "fataal" foutbericht zal zijn. Modulen zoals Try::Tiny maken een scope-lokale variabele speciaal voor dit doel.

Voorbeeld:

try {
    die "Boom!";
}
catch {
    print "Gevangen: $_
"; # $_ - valstrik van de fout binnen catch
};

Typische fouten en anti-patronen

Het negeren van de waarde van $@ na eval (fout niet opgemerkt).
Mutatie van $@ tussen meerdere eval zonder te bewaren.
Het gebruik van simpele die zonder try/catch voor kritische operaties.
Geen foutlogging.
Poging om niet-PERL-gerelateerde fouten op te vangen (bijvoorbeeld besturingssysteemsignalen).

Voorbeeld uit het leven

Negatief geval

In de handler voor gegevensexport wordt een fout bij het verbinden met de database opgevangen via eval, maar de waarde van $@ wordt niet bewaard, logging wordt niet uitgevoerd. Wanneer de volgende eval een andere fout oproept, gaat de eerste volledig verloren.

Voordelen:

De code crasht niet onmiddellijk in geval van een fout, blijft werken.

Nadelen:

Tijdens debugging is het onmogelijk om te begrijpen waarom de export niet werkt, er zijn geen foutmeldingen.
Mogelijke duplicaten of valse foutmeldingen.

Positief geval

Gebruik van Try::Tiny voor foutafhandeling in kritische secties, alle fouten worden in een aparte log geschreven, de originele fout wordt bewaard en correct weergegeven op het scherm.