Odpowiedź.

Perl został pierwotnie zaprojektowany jako język skryptowy do administracji systemowej, dlatego tradycyjny model obsługi błędów był bardziej proceduralny. Z biegiem czasu w języku pojawiły się rozszerzone techniki obsługi wyjątków i błędów.

Historia pytania

W pierwszych wersjach Perla błędy łapano poprzez zwracane wartości funkcji i sprawdzanie globalnej zmiennej $!, później pojawiły się konstrukcje eval (dynamiczne przechwytywanie), a moduły takie jak Try::Tiny dodały zwięzłe, bezpieczne wzorce try-catch.

Problem

Standardowy Perl nie ma wbudowanego składni try-catch. Błędy mogą występować zarówno w kodzie Perl, jak i w wywołaniach zewnętrznych (np. otwieranie plików). Jeśli błędy nie są obsługiwane jawnie, program może kontynuować działanie w nieprzewidywalnym stanie. Należy mądrze wybierać technikę przechwytywania błędów w zależności od kontekstu, złożoności aplikacji i wymagań dotyczących niezawodności.

Rozwiązanie

Do przechwytywania błędów w Perl używa się funkcji eval, otaczając potencjalnie niebezpieczny kod w bloku i analizując zawartość $@ po wykonaniu
Do tworzenia własnych błędów używa się die. Bardziej precyzyjne generowanie błędów i ponowne zgłaszanie już opisanych wyjątków — za pomocą frameworka sinon
Do „ludzkiej” obsługi błędów wygodnie jest używać zewnętrznych modułów (np. Try::Tiny)

Przykład kodu — obsługa błędów przez Try::Tiny:

use Try::Tiny;

try {
    open my $fh, '<', 'file.txt' or die "Nie można otworzyć pliku: $!";
    while (<$fh>) {
        print $_;
    }
}
catch {
    warn "Wystąpił błąd: $_";
};

Kluczowe cechy:

Mechanizm błędów jest asynchroniczny — błędy wewnątrz eval i try/catch nie zmieniają głównego ciągu wykonania, dopóki nie zostaną jawnie obsługiwane
Przechwytywanie błędów możliwe jest na różnych poziomach — low-level die/warn/return lub high-level try/catch w modułach
Moduły pozwalają uniknąć typowych błędów z eval związanych z nadpisywaniem $@ i pułapkami scope

Pytania z haczykiem.

W jakim przypadku blok eval nie przechwyci błędu systemowego?

Eval nie zawsze przechwytuje błąd, jeśli w środku dochodzi do fatalnego wyjścia w bibliotekach C (np. SEGFAULT z kodu XS). Eval działa tylko z fatalnymi błędami Perla, a nie z awariami rozszerzeń C.

Co się stanie z zmienną $@ w zagnieżdżonych blokach eval?

Jeśli wewnątrz eval wywoła się jeszcze jeden eval, to po jego wyjściu wartość $@ zostanie nadpisana. Dlatego po każdym eval warto przechowywać $@ w osobnej zmiennej do następnego eval, aby nie stracić oryginalnego błędu.

Dlaczego pomocnicze moduły typu Try::Tiny deklarują zmienną $@ lokalnie wewnątrz catch/try?

Ponieważ Perl automatycznie czyści $@ tylko przy pomyślnym wyjściu z try (eval). Powrót w przypadku błędu, next, last może spowodować, że $@ pozostanie nieczyszczony i w następnym kodzie będzie „widmo” błędu. Moduły typu Try::Tiny tworzą zmienną scope-local właśnie w tym celu.

Przykład:

try {
    die "Boom!";
}
catch {
    print "Złapano: $_
"; # $_ - pułapka błędu wewnątrz catch
};

Typowe błędy i antywzorce

Ignorowanie wartości $@ po eval (błąd niezauważony)
Mutacja $@ pomiędzy wieloma eval bez zapisu
Używanie prostego die bez try/catch do krytycznych operacji
Brak logowania błędu
Próba przechwycenia błędów niepowiązanych z Perlem (np. sygnały OS)

Przykład z życia

Negatywny przypadek

W obsłudze eksportu danych błąd podczas łączenia z bazą danych jest łapany przez eval, ale wartość $@ nie jest zapisywana, logowanie nie zostało wykonane. Gdy w następnym eval występuje inny błąd, pierwszy jest całkowicie tracony.

Zalety:

Kod nie pada od razu w przypadku błędu, kontynuuje działanie

Wady:

Podczas debugowania trudno zrozumieć, dlaczego eksport nie działa, brak komunikatów o błędach
Możliwość wystąpienia dublujących się lub fałszywych błędów

Pozytywny przypadek

Użycie Try::Tiny do obsługi krytycznych sekcji, wszystkie błędy są zapisywane w osobnym logu, oryginalny błąd jest zachowywany i poprawnie wyświetlany na ekranie.