Moduł szósty stanowi kompleksowe omówienie zaawansowanych mechanizmów obsługi wyjątków w języku Python, przeznaczony dla średniozaawansowanych programistów. Omówiono w nim hierarchię wyjątków dziedziczącą po klasie BaseException, pełną składnię try-except-else-finally oraz techniki aliasowania i przechwytywania wielu błędów jednocześnie. Przedstawiono również tworzenie własnych klas wyjątków, instrukcję raise do jawnego zgłaszania błędów oraz łączenie wyjątków za pomocą Exception Chaining. Kolejne zagadnienia to menedżery kontekstu z protokołem with, dekorator contextmanager z modułu contextlib, a także wprowadzone w Pythonie 3.11 grupy wyjątków ExceptionGroup ze składnią except*. Całość wieńczy omówienie dobrych praktyk, takich jak unikanie łapania ogólnego Exception, cichego ignorowania błędów oraz stosowanie precyzyjnych komunikatów zgodnych ze standardem PEP 8.

Kluczowe zagadnienia modułu:

• Hierarchia wyjątków — zasady dziedziczenia po klasach BaseException i Exception
• Składnia try-except-else-finally — pełna obsługa błędów z blokami else i finally
• Aliasowanie i wiele błędów — przechwytywanie wielu wyjątków w jednym bloku except
• Własne wyjątki, raise i Exception Chaining — tworzenie klas błędów, jawne zgłaszanie i łączenie wyjątków
• Menedżery kontekstu i ExceptionGroup — protokół with, dekorator @contextmanager i grupy wyjątków z Pythona 3.11
• Dobre praktyki obsługi błędów — precyzyjne komunikaty i unikanie antywzorców zgodnie z PEP 8

Wprowadzenie do zagadnienia: Hierarchia wyjątków w Pythonie. Wszystkie wyjątki w Pythonie dziedziczą po klasie BaseException. Bezpośrednio pod nią znajduje się Exception, z której wywodzą się wszystkie błędy aplikacji. Znajomość hierarchii wyjątków pozwala precyzyjnie określić, które błędy chcemy obsłużyć, a które pozostawić do propagacji. Świadome korzystanie z klas wyjątków ułatwia pisanie kodu odpornego na niespodziewane sytuacje.

• Hierarchia wyjątków w Pythonie jest strukturą dziedziczenia - wszystkie wyjątki wywodzą się z BaseException.
• Klasa Exception jest bazą dla większości błędów aplikacji - od niej dziedziczą ValueError, TypeError itd.
• Łapanie BaseException zamiast Exception może przechwycić SystemExit i KeyboardInterrupt, co zwykle jest niepożądane.
• Własne wyjątki należy wyprowadzać z Exception, nie z BaseException.
• Znajomość hierarchii pomaga w precyzyjnym łapaniu tylko tych błędów, które faktycznie możemy obsłużyć.

Hierarchię wyjątków wykorzystuje się w blokach except, wskazując konkretną klasę błędu do przechwycenia. Kolejność bloków except ma znaczenie - najpierw wyspecjalizowane, potem ogólne.

• Składnia except ValueError łapie tylko błędy typu ValueError, a except Exception łapie wszystkie wyjątki aplikacji.
• Kolejność bloków except ma znaczenie - Python sprawdza je po kolei, dlatego konkretne wyjątki powinny być pierwsze.
• Można użyć except (ValueError, TypeError) aby przechwycić kilka typów błędów w jednym bloku.
• Pusta instrukcja except (bez nazwy klasy) łapie wszystkie wyjątki, ale to utrudnia debugowanie.
• Zawsze warto określić typ wyjątku, aby nie maskować nieoczekiwanych błędów.

# Przykład składniowy dla hierarchii wyjątków w Pythonie
def demonstracja_składni():
    try:
        raise Exception()
    except Exception as dane:
        print(dane)

demonstracja_składni()
            

W praktyce hierarchia wyjątków przydaje się przy budowie bibliotek - wystarczy, że użytkownik złapie bazową klasę błędu biblioteki, a obsłuży wszystkie jej pochodne.

• Własne hierarchie wyjątków tworzy się dziedzicząc po Exception, co pozwala na grupowanie błędów domenowych.
• Biblioteki często definiują bazową klasę LibraryError, a po niej dziedziczą bardziej szczegółowe błędy.
• Użytkownik biblioteki może złapać LibraryError i obsłużyć wszystkie błędy biblioteki naraz.
• W aplikacjach webowych hierarchia pomaga w mapowaniu błędów na odpowiednie kody HTTP.
• Dobrze zaprojektowana hierarchia wyjątków ułatwia testowanie i debugowanie systemu.

# Realistyczny przykład użycia hierarchii wyjątków w Pythonie w projekcie
def analiza_danych_wejsciowych(kolekcja):
    try:
        raise Exception()
    except Exception as wynik:
        print(f"Przetworzono pomyślnie")
        return wynik
            

Typowym błędem jest łapanie zbyt ogólnych wyjątków, np. except BaseException, co przechwytuje nawet SystemExit i KeyboardInterrupt. Inny częsty problem to nieprawidłowa kolejność bloków except.

• Łapanie BaseException zamiast Exception może wyciszyć błędy krytyczne, takie jak przerwanie programu przez użytkownika.
• Zła kolejność bloków except powoduje, że wąski wyjątek jest przesłaniany przez szerszy i nigdy nie zostanie obsłużony.
• Używanie gołego except: (bez typu) jest uznawane za złą praktykę, chyba że w konkretnym, uzasadnionym przypadku.
• Tworzenie własnych wyjątków nie dziedziczących po Exception utrudnia ich obsługę.
• W Python 3 nie można rzucać wyjątków, które nie dziedziczą po BaseException - to powoduje TypeError.

# BŁĘDNE vs POPRAWNE użycie hierarchii wyjątków w Pythonie
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
def poprawna_metoda():
    try:
        dane_wejściowe = "poprawna wartość"
    except Exception:
        dane_wejściowe = None
    return dane_wejściowe
            

Opanowanie hierarchii wyjątków to podstawa świadomej obsługi błędów. Pozwala precyzyjnie decydować, które wyjątki obsłużyć, a które propagować wyżej.

• Pamiętaj o hierarchii: BaseException ← Exception ← {ValueError, TypeError, OSError, ...}.
• Łap tylko te wyjątki, które faktycznie umiesz obsłużyć - resztę propaguj dalej.
• Przy tworzeniu własnych wyjątków dziedzicz po Exception lub jego podklasach.
• Używaj konkretnych klas wyjątków w blokach except, nie ogólnego Exception bez konieczności.
• Hierarchia wyjątków to narzędzie, nie przeszkoda - używaj jej świadomie.

# Optymalne i kompletne podsumowanie Hierarchia wyjątków w Pythonie
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Hierarchia wyjątków w Pythonie
    print(f"System gotowy do pracy z Hierarchia wyjątków w Pythonie")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Składnia try-except-else-finally. Blok else wykonuje się wyłącznie wtedy, gdy w try nie wystąpił żaden błąd. Blok finally wykonuje się zawsze, co czyni go idealnym do zwalniania zasobów. Bloki try, except, else i finally dają pełną kontrolę nad przepływem sterowania w sytuacjach wyjątkowych. else uruchamia się tylko przy braku błędu, a finally zawsze.

• Blok try definiuje kod, który może zgłosić wyjątek.
• Blok except przechwytuje i obsługuje wyjątki określonego typu.
• Blok else wykonuje się tylko wtedy, gdy blok try nie zgłosił żadnego wyjątku.
• Blok finally wykonuje się zawsze, niezależnie od tego, czy wystąpił wyjątek, czy nie.
• Finally jest idealny do zwalniania zasobów, takich jak pliki, sockety czy połączenia z bazą danych.

Składnia bloków try-except-else-finally jest prosta, ale wymaga zrozumienia kolejności wykonywania. else uruchamia się tylko przy braku błędu w try, a finally zawsze na końcu.

• Kolejność bloków: try → except (opcjonalnie) → else (opcjonalnie) → finally (opcjonalnie).
• Else nie może wystąpić bez bloku except - musi być co najmniej jeden except lub finally.
• Finally wykonuje się nawet przy return, break, continue w try lub except.
• Jeśli wyjątek nie zostanie złapany w except, finally i tak się wykona przed propagacją błędu.
• Blok else to dobre miejsce na kod, który może sam zgłaszać wyjątki - oddziela logikę sukcesu od obsługi błędów.

# Przykład składniowy dla składni try-except-else-finally
def demonstracja_składni():
    # Prezentacja standardowego zapisu
    try:
        dane = "sukces"
    except:
        dane = "błąd"
    else:
        print("Bez błędów")
    finally:
        print(dane)

demonstracja_składni()
            

W praktyce else jest używane do umieszczenia kodu, który powinien wykonać się tylko po udanej operacji. Finally służy do zamykania plików, zwalniania blokad czy zamykania połączeń sieciowych.

• W operacjach na plikach finally gwarantuje zamknięcie uchwytu nawet przy błędzie odczytu.
• W transakcjach bazodanowych else może potwierdzić transakcję, a finally zamknąć połączenie.
• W aplikacjach sieciowych finally zamyka gniazdo, zapobiegając wyciekom zasobów.
• Else pomaga oddzielić kod sukcesu od kodu obsługi błędów, co zwiększa czytelność.
• W połączeniu z return, finally nadal się wykonuje - to cecha odróżniająca Pythona od wielu innych języków.

# Realistyczny przykład użycia składni try-except-else-finally w projekcie
def analiza_danych_wejsciowych(kolekcja):
    # Przetwarzanie i transformacja z użyciem optymalnych struktur
    try:
        wynik = kolekcja
    except:
        wynik = None
    else:
        print(f"Przetworzono pomyślnie")
    finally:
        print("Koniec")
    return wynik
            

Częstym błędem jest umieszczanie kodu w try, który powinien być w else - prowadzi to do maskowania błędów. Inny antywzorzec to używanie finally do zwracania wartości, co nadpisuje ewentualną wartość zwróconą przez try lub except.

• Używanie try do kodu, który nie zgłasza wyjątków, jest niepotrzebne i zaciemnia intencję.
• Zwracanie wartości z finally nadpisuje wartość zwróconą przez try/except i może ukryć błąd.
• Zbyt duży blok try utrudnia określenie, która linia faktycznie zgłosiła wyjątek.
• Pominięcie finally przy pracy z zasobami (pliki, sockety) prowadzi do ich wycieku.
• Używanie else bez except jest błędem składniowym - Python tego nie dopuszcza.

# BŁĘDNE vs POPRAWNE użycie składni try-except-else-finally
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
def poprawna_metoda():
    try:
        dane_wejściowe = "poprawna wartość"
    except:
        dane_wejściowe = "wartość po błędzie"
    finally:
        print("Zawsze wykonane")
    return dane_wejściowe
            

Znajomość składni try, except, else i finally pozwala precyzyjnie sterować przepływem w sytuacjach wyjątkowych. Właściwe użycie tych bloków to podstawa solidnej obsługi błędów w Pythonie.

• Używaj try tylko dla kodu, który faktycznie może zgłosić wyjątek.
• W else umieszczaj kod, który zależy od powodzenia try.
• W finally umieszczaj kod zwalniający zasoby - wykona się zawsze.
• Unikaj pustych bloków except - ciche ignorowanie błędów jest niebezpieczne.
• Pamiętaj, że finally może być użyte bez except, np. do gwarantowanego zwolnienia zasobu.

# Optymalne i kompletne podsumowanie Składnia try-except-else-finally
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Składnia try-except-else-finally
    print(f"System gotowy do pracy z Składnia try-except-else-finally")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Aliasowanie i przechwytywanie wielu błędów. Możemy przechwycić kilka różnych wyjątków w jednym bloku except, umieszczając je w krotce. Użycie as e pozwala na dostęp do obiektu wyjątku. Aliasowanie wyjątków przez as e oraz przechwytywanie wielu typów w jednym bloku except to techniki redukujące powielanie kodu. Pozwalają elegancko obsłużyć grupę podobnych błędów w jednym miejscu.

• Składnia except (ValueError, TypeError) as e łapie wiele typów wyjątków w jednym bloku.
• Nawiasy są obowiązkowe - bez nich Python zinterpretuje to jako zagnieżdżone except.
• Alias e daje dostęp do instancji wyjątku, w tym do atrybutów takich jak args.
• Po opuszczeniu bloku except zmienna e jest usuwana (Python 3.12+ wywołuje błąd NameError).
• W Pythonie 3.11+ można używać except* do równoległej obsługi wyjątków z ExceptionGroup.

Składnia except (ValueError, TypeError) as e: wymaga nawiasów wokół krotki typów. Kluczowe jest, że alias e jest usuwany po wyjściu z bloku except.

• Zapis except ValueError, TypeError: (bez nawiasu) jest niepoprawną składnią w Pythonie 3.
• Poprawny zapis: except (ValueError, TypeError) as e:.
• Można mieszać typy z różnych gałęzi hierarchii, np. (OSError, ValueError).
• Zmienna e w as e jest instancją przechwyconego wyjątku.
• Użycie as jest opcjonalne - jeśli nie potrzebujesz obiektu wyjątku, pomiń je.

# Przykład składniowy dla aliasowania i przechwytywania wielu błędów
def demonstracja_składni():
    # Prezentacja standardowego zapisu
    try:
        print("kod z potencjalnym błędem")
    except (ValueError, TypeError) as e:
        dane = e
        print(dane)

demonstracja_składni()
            

W praktyce aliasowanie wyjątków przydaje się, gdy różne operacje generują podobne błędy, a my chcemy obsłużyć je w jeden sposób. Na przykład konwersja danych może rzucać ValueError, TypeError lub UnicodeDecodeError.

• Parsowanie danych wejściowych może rzucać ValueError, TypeError lub UnicodeError - wszystkie można złapać w jednym except.
• Operacje sieciowe często grupują ConnectionError, TimeoutError i OSError.
• Dostęp do plików może generować FileNotFoundError, PermissionError i IsADirectoryError.
• Alias e pozwala zalogować szczegóły błędu bez przerywania przepływu.
• Łączenie błędów w krotkę redukuje powielanie kodu i zwiększa czytelność.

# Realistyczny przykład użycia aliasowania i przechwytywania wielu błędów w projekcie
def analiza_danych_wejsciowych(kolekcja):
    try:
        wynik = int(kolekcja)
    except (ValueError, TypeError) as e:
        wynik = 0
        print(f"Błąd: {e}")
    print(f"Przetworzono pomyślnie")
    return wynik
            

Częstym błędem jest pomijanie nawiasów przy krotce wyjątków. Inny błąd to łapanie zbyt wielu typów w jednym bloku, co zaciemnia logikę.

• Brak nawiasów w except ValueError, TypeError as e: oznacza coś innego - łapie ValueError, a TypeError przypisuje do e.
• Zbyt wiele typów w krotce utrudnia zrozumienie, które błędy faktycznie są obsługiwane.
• Mieszanie niepowiązanych typów sugeruje, że blok except robi zbyt wiele naraz.
• Używanie aliasu e poza blokiem except (w Pythonie 3.11-) może prowadzić do błędów.
• W Pythonie 3.12+ alias e jest domyślnie usuwany po bloku - nie polegaj na nim później.

# BŁĘDNE vs POPRAWNE użycie aliasowania i przechwytywania wielu błędów
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
def poprawna_metoda():
    try:
        dane_wejściowe = 42
    except (ValueError, TypeError) as e:
        dane_wejściowe = 0
    return dane_wejściowe
            

Aliasowanie i grupowanie wyjątków to techniki redukujące powielanie kodu przy zachowaniu precyzji obsługi błędów. Stosuj je, gdy kilka typów błędów wymaga tej samej reakcji.

• Grupuj tylko powiązane typy wyjątków, które wymagają tej samej reakcji.
• Zawsze używaj nawiasów: except (ValueError, TypeError) as e:.
• Alias e używaj, gdy potrzebujesz dostępu do szczegółów błędu.
• Nie polegaj na zmiennej aliasu poza blokiem except.
• Jeśli obsługa różni się dla różnych typów, rozdziel je na osobne bloki except.

# Optymalne i kompletne podsumowanie Aliasowanie i przechwytywanie wielu błędów
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Aliasowanie i przechwytywanie wielu błędów
    print(f"System gotowy do pracy z Aliasowanie i przechwytywanie wielu błędów")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Tworzenie własnych wyjątków. Aby stworzyć własny wyjątek, definiujemy nową klasę dziedziczącą po Exception. Pozwala to na precyzyjne sygnalizowanie specyficznych błędów domenowych. Tworzenie własnych klas wyjątków pozwala na precyzyjne sygnalizowanie błędów specyficznych dla domeny aplikacji. Dziedzicząc po Exception, możemy definiować hierarchię błędów dostosowaną do potrzeb naszego projektu.

• Własne wyjątki tworzy się przez dziedziczenie po Exception lub jego podklasie.
• Wystarczy pusta klasa z pass - Python sam obsługuje mechanizm wyjątków.
• Można dodawać własne atrybuty do przechowywania dodatkowych informacji o błędzie.
• Własne wyjątki umożliwiają precyzyjne komunikaty błędów dla użytkownika i debugera.
• Nazwy własnych wyjątków powinny kończyć się na Error (zgodnie z PEP 8).

Definicja własnego wyjątku to zwykła klasa dziedzicząca po Exception. Można dodać konstruktor przyjmujący dodatkowe parametry.

• Składnia: class MojBlad(Exception):, ewentualnie z metodą __init__.
• Konstruktor może przyjmować dowolne argumenty, np. kod błędu i opis.
• Domyślny konstruktor Exception przyjmuje *args i przechowuje w args.
• Można definiować własne atrybuty, np. self.kod = kod.
• Nazewnictwo: konkretny błąd powinien kończyć się na Error.

# Przykład składniowy dla tworzenia własnych wyjątków
class MojBlad(Exception):
    pass

def demonstracja_składni():
    dane = MojBlad("Własny błąd")
    print(dane)

demonstracja_składni()
            

W praktyce własne wyjątki są używane w bibliotekach do definiowania domenowych błędów, np. ValidationError w Django, RequestError w requests. Pozwala to na precyzyjną obsługę błędów.

• W aplikacjach webowych własne wyjątki mapują się na kody błędów HTTP i komunikaty JSON.
• W systemach ETL własne wyjątki sygnalizują konkretne problemy z transformacją danych.
• Biblioteki definiują bazowy wyjątek, po którym dziedziczą wszystkie specyficzne błędy.
• W aplikacjach CLI własne wyjątki umożliwiają wyświetlanie czytelnych komunikatów dla użytkownika.
• W testach własne wyjątki pozwalają sprawdzić, czy funkcja rzuca oczekiwany błąd.

# Realistyczny przykład użycia tworzenia własnych wyjątków w projekcie
class MojBlad(Exception):
    pass

def analiza_danych_wejsciowych(kolekcja):
    if not kolekcja:
        raise MojBlad("Nieprawidłowa kolekcja")
    wynik = kolekcja
    print(f"Przetworzono pomyślnie")
    return wynik
            

Częstym błędem jest dziedziczenie po BaseException zamiast Exception, co utrudnia obsługę. Inny antywzorzec to tworzenie zbyt szczegółowej hierarchii, która zaciemnia kod.

• Dziedziczenie po BaseException jest rzadko potrzebne - utrudnia złapanie błędu.
• Zbyt głęboka hierarchia wyjątków utrudnia zrozumienie kodu, a nie pomaga.
• Niedefiniowanie własnych wyjątków w bibliotece - użytkownicy muszą łapać ogólne Exception.
• Brak dokumentacji, które wyjątki rzuca dana funkcja - utrudnia użycie API.
• Rzucanie wyjątku z błędnym komunikatem lub bez komunikatu - utrudnia debugowanie.

# BŁĘDNE vs POPRAWNE użycie tworzenia własnych wyjątków
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
class MojBlad(Exception):
    pass

def poprawna_metoda():
    dane_wejściowe = MojBlad()
    return dane_wejściowe
            

Własne wyjątki to kluczowe narzędzie do budowania czytelnych API i precyzyjnej komunikacji błędów. Projektuj je tak, aby użytkownik twojego kodu wiedział dokładnie, co się stało.

• Nazywaj własne wyjątki z sufiksem Error, np. ValidationError, ConnectionError.
• Dziedzicz po Exception, a nie BaseException.
• Dokumentuj, które wyjątki może rzucać twoja funkcja lub biblioteka.
• Postaraj się o czytelne komunikaty błędów, które pomagają w debugowaniu.
• Nie tworz zbyt wielu poziomów hierarchii - zachowaj prostotę.

# Optymalne i kompletne podsumowanie Tworzenie własnych wyjątków
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Tworzenie własnych wyjątków
    print(f"System gotowy do pracy z Tworzenie własnych wyjątków")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Zgłaszanie błędów za pomocą raise. Instrukcja raise służy do jawnego zgłaszania wyjątków. Wywołanie raise bez argumentów wewnątrz bloku except powoduje ponowne rzucenie złapanego błędu. Instrukcja raise to podstawowe narzędzie do jawnego zgłaszania wyjątków w Pythonie. Użycie raise bez argumentów wewnątrz bloku except powoduje ponowne rzucenie bieżącego wyjątka.

• raise instancja_wyjątku - rzuca konkretny wyjątek z komunikatem.
• raise sama w sobie (w bloku except) - ponownie rzuca ten sam wyjątek.
• raise klasa_wyjątku - tworzy instancję bez argumentów i rzuca.
• raise NowyBlad from stary - łańcuchowanie wyjątków (Exception Chaining).
• raise poza blokiem except bez argumentu powoduje RuntimeError.

Składnia raise jest elastyczna - można rzucać instancję wyjątku, samą klasę albo ponownie rzucać istniejący wyjątek. Kluczowe jest zrozumienie, kiedy użyć której formy.

• raise ValueError("komunikat") rzuca nowy wyjątek z komunikatem.
• raise (bez argumentów) działa tylko wewnątrz bloku except - ponownie rzuca bieżący wyjątek.
• raise ValueError to skrót od raise ValueError().
• raise from tworzy łańcuch przyczynowo-skutkowy między wyjątkami.
• raise bez argumentu poza except rzuca RuntimeError("No active exception to reraise").

# Przykład składniowy dla zgłaszania błędów za pomocą raise
def demonstracja_składni():
    try:
        raise ValueError('Zły format')
    except ValueError as dane:
        print(dane)

demonstracja_składni()
            

W praktyce raise jest używane do walidacji danych wejściowych, sygnalizowania błędów stanu aplikacji oraz propagacji wyjątków między warstwami architektury.

• Walidacja wejścia: raise ValueError("Nieprawidłowa wartość") przy błędnych danych użytkownika.
• Propagacja z logowaniem: złap wyjątek, zaloguj, raise bez argumentu zachowuje traceback.
• W funkcjach narzędziowych: raise TypeError przy błędnym typie argumentu.
• W warstwie serwisowej: przechwyć błąd niższego poziomu, zaloguj i rzuć własny wyjątek.
• W testach: assertRaises sprawdza, czy funkcja rzuca oczekiwany wyjątek.

# Realistyczny przykład użycia zgłaszania błędów za pomocą raise w projekcie
def analiza_danych_wejsciowych(kolekcja):
    if not kolekcja:
        raise ValueError('Zły format')
    wynik = kolekcja
    print(f"Przetworzono pomyślnie")
    return wynik
            

Typowym błędem przy używaniu raise jest ponowne rzucenie wyjątku bez argumentów poza blokiem except, co powoduje RuntimeError.

• raise bez argumentu poza blokiem except - błąd RuntimeError.
• Używanie raise z ogólnym Exception zamiast konkretną klasą błędu.
• Rzucanie wyjątku z pustym komunikatem - utrudnia debugowanie.
• Używanie raise do sterowania przepływem zamiast do obsługi błędów.
• Złapanie wyjątku i natychmiastowe ponowne rzucenie bez logowania - tracisz kontekst.

# BŁĘDNE vs POPRAWNE użycie zgłaszania błędów za pomocą raise
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
def poprawna_metoda():
    if not dane_wejściowe:
        raise ValueError('Zły format')
    return dane_wejściowe
            

Raise to podstawowe narzędzie do sygnalizowania błędów w Pythonie. Używaj go z konkretnymi klasami wyjątków i czytelnymi komunikatami.

• Rzucaj konkretne typy wyjątków, nie ogólne Exception.
• Dołączaj czytelne komunikaty, które pomagają w debugowaniu.
• Używaj raise bez argumentów tylko do ponownego rzucenia w except.
• Stosuj raise ... from ... do łańcuchowania powiązanych błędów.
• Nie używaj raise do kontroli przepływu - to antywzorzec.

# Optymalne i kompletne podsumowanie Zgłaszanie błędów za pomocą raise
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Zgłaszanie błędów za pomocą raise
    print(f"System gotowy do pracy z Zgłaszanie błędów za pomocą raise")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Łączenie wyjątków (Exception Chaining). Składnia raise NowyBlad from e pozwala na powiązanie nowego wyjątku z pierwotną przyczyną, co ułatwia debugowanie i zachowuje historię błędów. Exception Chaining przez raise ... from ... pozwala zachować pełny łańcuch przyczynowo-skutkowy błędów, co jest nieocenione przy debugowaniu złożonych systemów.

• raise BladB from bladA tworzy łańcuch - BladB jest nowym wyjątkiem, bladA jest przyczyną.
• Python automatycznie ustawia __cause__ i __context__ na obiekcie wyjątku.
• Traceback wyświetla pełny łańcuch: "The above exception was the direct cause...".
• raise ... from None ukrywa pierwotną przyczynę - używaj rzadko i świadomie.
• Exception Chaining zachowuje historię błedów bez konieczności ręcznego logowania.

Składnia jest prosta: raise NowyException("opis") from stary_wyjatek. from przyjmuje instancję wyjątku, która będzie przechowywana jako __cause__ nowego wyjątku.

• raise ValueError("nowy") from OSError("stary") - ValueError ma __cause__ ustawione na OSError.
• from może wskazywać na instancję wyjątku lub na None.
• raise ... from None jest używane, gdy chcesz ukryć szczegóły implementacji.
• Niejawne łańcuchowanie (łączenie kontekstowe): jeśli w except pojawi się nowy wyjątek bez from, Python ustawia __context__.
• __cause__ (jawny) i __context__ (domyślny) to dwa różne atrybuty łańcucha.

# Przykład składniowy dla łączenia wyjątków (Exception Chaining)
class MojBlad(Exception):
    pass

def demonstracja_składni():
    try:
        raise ValueError("błąd źródłowy")
    except ValueError as e:
        raise MojBlad("nowy błąd") from e

demonstracja_składni()
            

W praktyce łączenie wyjątków stosuje się podczas konwersji błędów niskiego poziomu na wyjątki domenowe. Na przykład błąd bazy danych można opakować w własny DatabaseError z zachowaniem oryginalnej przyczyny.

• Błąd SQL → repack na DatabaseError z from, co zachowuje oryginalny komunikat błędu SQL.
• Błąd sieci → opakowanie w ConnectionFailedError z from zachowuje szczegóły timeoutu.
• Walidacja danych → błąd z biblioteki zewnętrznej opakowany w domenowy ValidationError.
• Łączenie pozwala zachować pełny stack trace od źródła do miejsca łapania.
• Użycie from None jest rzadkie, ale przydatne przy implementacji interfejsów API.

# Realistyczny przykład użycia łączenia wyjątków (Exception Chaining) w projekcie
class MojBlad(Exception):
    pass

def analiza_danych_wejsciowych(kolekcja):
    try:
        wynik = int(kolekcja)
    except ValueError as e:
        raise MojBlad("Błąd przetwarzania") from e
    print(f"Przetworzono pomyślnie")
    return wynik
            

Częstym błędem jest używanie raise ... from None bez uzasadnienia, co traci informacje o przyczynie błędu.

• Zbyt częste raise ... from None ukrywa przyczynę błędu i utrudnia debugowanie.
• Brak from przy konwersji wyjątków - Python tworzy niejawne chainowanie (__context__).
• Mylenie __cause__ i __context__ prowadzi do nieporozumień w interpretacji tracebacka.
• Łańcuchowanie z niepowiązanymi wyjątkami - from wskazuje na przypadkowy błąd.
• Zapominanie o from przy refaktoryzacji - nowy wyjątek bez powiązania z oryginalnym błędem.

# BŁĘDNE vs POPRAWNE użycie łączenia wyjątków (Exception Chaining)
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
class MojBlad(Exception):
    pass

def poprawna_metoda():
    try:
        dane_wejściowe = "wartość"
        int(dane_wejściowe)
    except ValueError as e:
        raise MojBlad("Błąd konwersji") from e
    return dane_wejściowe
            

Łączenie wyjątków przez from to potężne narzędzie debugowania, które pozwala zachować pełny łańcuch przyczynowo-skutkowy błędów bez zaciemniania kodu.

• Używaj raise NowyBlad from staryBlad przy konwersji typów błędów.
• Unikaj raise ... from None, chyba że masz konkretny powód do ukrycia przyczyny.
• Pamiętaj, że __cause__ i __context__ to różne atrybuty - pierwszy jawny, drugi domyślny.
• Exception Chaining ułatwia debugowanie złożonych systemów wielowarstwowych.
• Nie używaj from do niepowiązanych błędów - chainowanie ma sens tylko przy związkach przyczynowych.

# Optymalne i kompletne podsumowanie Łączenie wyjątków (Exception Chaining)
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Łączenie wyjątków (Exception Chaining)
    print(f"System gotowy do pracy z Łączenie wyjątków (Exception Chaining)")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Menedżery kontekstu (protokół with). Menedżer kontekstu gwarantuje bezpieczne zarządzanie zasobami poprzez automatyczne wywołanie metod magicznych __enter__ i __exit__ przy wejściu i wyjściu. Menedżery kontekstu z protokołem with gwarantują bezpieczne zarządzanie zasobami poprzez automatyczne wywołanie metod __enter__ i __exit__. To najbezpieczniejszy sposób pracy z plikami, połączeniami i blokadami w Pythonie.

• Instrukcja with automatycznie wywołuje __enter__ na początku i __exit__ na końcu bloku.
• Menedżer kontekstu gwarantuje zwolnienie zasobu nawet przy wyjątku w bloku with.
• Najpopularniejszy przykład: with open("plik.txt") as f: - plik zostanie zamknięty automatycznie.
• __exit__ otrzymuje informację o wyjątku (typ, wartość, traceback) lub None przy sukcesie.
• Jeśli __exit__ zwróci True, wyjątek jest wyciszony - używaj ostrożnie.

Składnia with obiekt as zmienna: wymaga, by obiekt implementował metody __enter__ i __exit__. as zmienna jest opcjonalny.

• with open("f.txt") as f: - najczęstsze użycie, f jest obiektem pliku.
• with Menadżer(): - bez as, jeśli nie potrzebujemy wartośći zwracanej przez __enter__.
• with A() as a, B() as b: - zagnieżdżanie wielu menedżerów w jednej linii.
• with A(): with B(): - alternatywny zapis z rozdzielnymi blokami.
• W Pythonie 3.10+ można używać nawiasów: with (A() as a, B() as b):.

# Przykład składniowy dla menedżerów kontekstu (protokół with)
def demonstracja_składni():
    # Prezentacja standardowego zapisu
    with open('file.txt') as f:
        dane = f.read()
    print(dane)

demonstracja_składni()
            

W praktyce menedżery kontekstu są używane do zarządzania plikami, połączeniami sieciowymi, blokadami wątków, transakcjami bazodanowymi oraz tymczasowymi modyfikacjami stanu.

• Pliki: with open(...) as f: - automatyczne zamykanie, nawet przy błędzie.
• Blokady: with threading.Lock(): - bezpieczne synchronizowanie wątków.
• Bazy danych: with connection: - automatyczne zatwierdzanie/wycofanie transakcji.
• Testy: with pytest.raises(ValueError): - sprawdza, czy kod rzuca wyjątek.
• Tymczasowe zmiany: with redirect_stdout(buf): - przechwytywanie wyjścia.

# Realistyczny przykład użycia menedżerów kontekstu (protokół with) w projekcie
def analiza_danych_wejsciowych(kolekcja):
    # Przetwarzanie i transformacja z użyciem optymalnych struktur
    with open('file.txt') as f:
        wynik = f.read()
    print(f"Przetworzono pomyślnie")
    return wynik
            

Częstym błędem jest ręczne wywoływanie f.close() w bloku with, co jest zbędne. Inny antywzorzec to otwieranie pliku bez with, co grozi wyciekiem uchwytu przy wyjątku.

• Ręczne zamykanie pliku w with - podwójne zamknięcie, ale niepotrzebne i mylące.
• Otwieranie pliku bez with - wyciek uchwytu przy wyjątku przed f.close().
• Zwracanie True z __exit__ bez uzasadnienia - wycisza wszystkie wyjątki.
• Zbyt duży blok with - utrzymywanie zasobu dłużej niż potrzeba.
• Brak obsługi wyjątków wewnątrz with - __exit__ nie powinien rzucać własnych wyjątków.

# BŁĘDNE vs POPRAWNE użycie menedżerów kontekstu (protokół with)
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
def poprawna_metoda():
    with open('file.txt') as f:
        dane_wejściowe = f.read()
    return dane_wejściowe
            

Menedżery kontekstu z with to najbezpieczniejszy sposób zarządzania zasobami w Pythonie. Używaj ich zawsze, gdy pracujesz z plikami, połączeniami, blokadami.

• Zawsze używaj with z zasobami wymagającymi zwolnienia (pliki, sockety, blokady).
• Nie wywołuj ręcznego close() wewnątrz with.
• Używaj zagnieżdżonych with lub z wieloma menedżerami w jednej linii.
• Implementuj własne menedżery kontekstu przez klasę z __enter__/__exit__ lub @contextmanager.
• Nie zwracaj True z __exit__ bez wyraźnej potrzeby wyciszenia błędu.

# Optymalne i kompletne podsumowanie Menedżery kontekstu (protokół with)
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Menedżery kontekstu (protokół with)
    print(f"System gotowy do pracy z Menedżery kontekstu (protokół with)")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Klasa contextmanager z contextlib. Dekorator @contextmanager z modułu contextlib pozwala na tworzenie menedżerów kontekstu przy użyciu prostej funkcji z jedną instrukcją yield. Dekorator @contextmanager z modułu contextlib pozwala tworzyć menedżery kontekstu bez definiowania klasy - wystarczy funkcja generator z yield.

• @contextmanager zamienia funkcję generator w menedżer kontekstu.
• Kod przed yield to inicjalizacja (__enter__), kod po yield to finalizacja (__exit__).
• Wartość z yield jest zwracana przez with ... as zmienna:.
• Jeśli w bloku with wystąpi wyjątek, jest on propagowany do generatora w miejscu yield.
• Należy obsłużyć wyjątek wewnątrz funkcji lub pozwolić mu propagować.

Użycie @contextmanager wymaga importu z contextlib. Funkcja musi zawierać yield, a kod przed yield to wejście, po yield to wyjście.

• from contextlib import contextmanager - wymagany import.
• @contextmanager dekoruje funkcję z yield, zamieniając ją w menedżer kontekstu.
• Yield może zwrócić wartość dostępną jako zmienna w with ... as zmienna:.
• Kod po yield wykonuje się nawet przy wyjątku, ale tylko jeśli generator go obsłuży.
• Aby zagwarantować finalizację, używaj try-finally wokół yield.

# Przykład składniowy dla klasy contextmanager z contextlib
from contextlib import contextmanager

@contextmanager
def moj_kontekst():
    print("Wejście")
    yield
    print("Wyjście")

def demonstracja_składni():
    with moj_kontekst():
        dane = "w kontekście"
    print(dane)

demonstracja_składni()
            

W praktyce @contextmanager jest używany do tymczasowych zmian stanu, np. zmiana katalogu, ustawienie zmiennych środowiskowych, tymczasowe przekierowanie strumieni.

• Tymczasowa zmiana katalogu: z @contextmanager, yield, a potem powrót do oryginalnego katalogu.
• Pomiar czasu: @contextmanager zapisuje czas przed yield i po yield.
• Zmienne środowiskowe: tymczasowa zmiana os.environ z przywróceniem po yield.
• Przekierowanie stdout/stdin: tymczasowa podmiana sys.stdout na własny bufor.
• Transakcje bazodanowe: commit po yield, rollback przy wyjątku.

# Realistyczny przykład użycia klasy contextmanager z contextlib w projekcie
from contextlib import contextmanager

@contextmanager
def otworz_plik(nazwa):
    print(f"Otwieram {nazwa}")
    yield "zawartość pliku"
    print(f"Zamykam {nazwa}")

def analiza_danych_wejsciowych(kolekcja):
    with otworz_plik("dane.txt") as wynik:
        print(wynik)
    print(f"Przetworzono pomyślnie")
    return wynik
            

Częstym błędem jest brak obsługi wyjątków wewnątrz funkcji z @contextmanager - kod po yield nie wykona się, chyba że użyto try-finally.

• Brak try-finally wokół yield - kod po yield nie wykona się przy wyjątku.
• Zapomnienie o dekoratorze @contextmanager - funkcja działa jak zwykły generator.
• Zbyt skomplikowana logika wewnątrz funkcji - menedżer kontekstu powinien być prosty.
• Wielokrotny yield w jednej funkcji - @contextmanager obsługuje tylko jeden yield.
• Rzucanie wyjątku z __exit__ (kodu po yield) bez potrzeby - maskuje oryginalny błąd.

# BŁĘDNE vs POPRAWNE użycie klasy contextmanager z contextlib
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
from contextlib import contextmanager

@contextmanager
def zarzadzaj_zasobem():
    print("Inicjalizacja")
    yield
    print("Czyszczenie")

def poprawna_metoda():
    with zarzadzaj_zasobem():
        dane_wejściowe = "wynik"
    return dane_wejściowe
            

@contextmanager to wygodny sposób na szybkie tworzenie menedżerów kontekstu bez pisania klasy. Sprawdza się przy prostych przypadkach tymczasowej zmiany stanu.

• Używaj @contextmanager dla prostych menedżerów kontekstu - dla złożonych lepiej użyć klasy.
• Zawsze opakowuj yield w try-finally, aby zagwarantować wykonanie kodu finalizującego.
• Importuj contextmanager z contextlib.
• Nie umieszczaj zbyt wiele logiki w jednym menedżerze kontekstu.
• Dokumentuj, co menedżer kontekstu robi, szczególnie jakie zasoby zarządza.

# Optymalne i kompletne podsumowanie Klasa contextmanager z contextlib
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Klasa contextmanager z contextlib
    print(f"System gotowy do pracy z Klasa contextmanager z contextlib")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Grupy wyjątków (ExceptionGroup). Wprowadzone w Pythonie 3.11 grupy wyjątków (ExceptionGroup) i składnia except* pozwalają na jednoczesne przechwytywanie i obsługę wielu niezależnych błędów. ExceptionGroup wprowadzony w Pythonie 3.11 umożliwia zgrupowanie wielu niezależnych wyjątków w jeden obiekt. Składnia except* pozwala na częściowe przechwytywanie.

• ExceptionGroup grupuje wiele wyjątków - przydaje się w programowaniu asynchronicznym i równoległym.
• except* działa podobnie do except, ale może częściowo obsłużyć grupę.
• Po except* nieobsłużone wyjątki pozostają w grupie i są propagowane dalej.
• ExceptionGroup("msg", [ValueError("msg1"), TypeError("msg2")]) - konstruktor z listą wyjątków.
• Wymaga Pythona 3.11 lub nowszego - nie działa we wcześniejszych wersjach.

Składnia except* różni się od except tym, że po obsłużeniu pasujących wyjątków, pozostałe są nadal dostępne w grupie.

• except* ValueError as eg: - przechwytuje wyjątki ValueError z ExceptionGroup do osobnej grupy eg.
• except* ValueError: - bez as, jeśli nie potrzebujesz obiektu grupy.
• Można użyć wielu except* dla różnych typów - każdy obsłuży swoją część grupy.
• except* nie może być mieszany z except (zwykłym) w tym samym try.
• Jeśli żaden except* nie pasuje, grupa propaguje się jako całość.

# Przykład składniowy dla grup wyjątków (ExceptionGroup)
def demonstracja_składni():
    try:
        raise ExceptionGroup('błędy', [ValueError('a'), TypeError('b')])
    except* ValueError as eg:
        for e in eg.exceptions:
            print(e)

demonstracja_składni()
            

W praktyce ExceptionGroup jest używana w asynchronicznych frameworkach oraz przy wykonywaniu wielu niezależnych zadań równolegle, gdzie każde może zakończyć się innym błędem.

• asyncio.gather() z return_exceptions=True - zbiera wszystkie wyjątki do listy.
• trio.Nursery - propaguje wszystkie błędy z zadań potomnych jako ExceptionGroup.
• Walidacja wielu pól formularza - każdy błąd walidacji to osobny wyjątek w grupie.
• Przetwarzanie wsadowe - błędy z każdego elementu partii są grupowane razem.
• except* pozwala obsłużyć część błędów i propagować resztę.

# Realistyczny przykład użycia grup wyjątków (ExceptionGroup) w projekcie
def analiza_danych_wejsciowych(kolekcja):
    try:
        raise ExceptionGroup('błędy', [ValueError('a'), TypeError('b')])
    except* ValueError as eg:
        wynik = eg
    print(f"Przetworzono pomyślnie")
    return wynik
            

Częstym błędem jest używanie except zamiast except* do łapania ExceptionGroup - zwykły except nie rozdziela grupy.

• Używanie except zamiast except* do łapania ExceptionGroup - grupa nie jest rozdzielana.
• Mieszanie except i except* w jednym try - błąd składni w Pythonie 3.11+.
• Tworzenie ExceptionGroup z jednym wyjątkiem - lepiej użyć zwykłego raise.
• Brak sprawdzenia wersji Pythona - ExceptionGroup wymaga 3.11 lub nowszego.
• Ignorowanie nieobsłużonych wyjątków w grupie - propagują się dalej.

# BŁĘDNE vs POPRAWNE użycie grup wyjątków (ExceptionGroup)
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
def poprawna_metoda():
    try:
        raise ExceptionGroup('błędy', [ValueError('x')])
    except* ValueError as eg:
        dane_wejściowe = eg
    return dane_wejściowe
            

ExceptionGroup i except* to nowoczesne narzędzie do obsługi wielu błędów jednocześnie. Szczególnie przydatne w kodzie asynchronicznym i równoległym.

• Używaj ExceptionGroup do grupowania niezależnych błędów z równoległych operacji.
• Stosuj except* do częściowej obsługi grupy - nieobsłużone błędy propagują się dalej.
• Nie mieszaj except i except* w tym samym bloku try.
• Sprawdź wersję Pythona - ExceptionGroup wymaga 3.11+.
• Nie twórz ExceptionGroup z pojedynczym wyjątkiem - użyj zwykłego raise.

# Optymalne i kompletne podsumowanie Grupy wyjątków (ExceptionGroup)
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Grupy wyjątków (ExceptionGroup)
    print(f"System gotowy do pracy z Grupy wyjątków (ExceptionGroup)")

if __name__ == "__main__":
    glowny_punkt_startowy()
            

Wprowadzenie do zagadnienia: Dobre praktyki obsługi błędów. Dobre praktyki obejmują unikanie łapania ogólnego Exception, cichego ignorowania błędów (pass) oraz dbanie o precyzyjne komunikaty błędów. Dobre praktyki obsługi błędów to fundament solidnego kodu: unikaj łapania ogólnego Exception, nie ignoruj błędów przez pass, dbaj o precyzyjne komunikaty.

• Zasada EAFP: łatwiej prosić o wybaczenie niż o pozwolenie - próbuj i łap błędy.
• Unikaj łapania ogólnego Exception - precyzyjnie określaj typ wyjątku.
• Nie używaj pustego except: pass - to najgorsza praktyka, wycisza wszystkie błędy.
• Zawsze loguj wyjątki - przynajmniej komunikat, najlepiej pełny traceback.
• Rzucaj wyjątki na odpowiednim poziomie abstrakcji - nie przeciekaj szczegółów implementacji.

Dobre praktyki to nie konkretna składnia, ale sposób stosowania poznanych konstrukcji. Kluczowe zasady: łap konkretne wyjątki, używaj else i finally zgodnie z przeznaczeniem.

• Używaj konkretnych klas wyjątków: except ValueError zamiast except Exception.
• Stosuj else dla kodu, który wykonuje się tylko po sukcesie try.
• Używaj finally do zwalniania zasobów.
• Dokumentuj wyjątki w docstringu: Raises: ValueError - gdy wejście jest nieprawidłowe.
• Stosuj raise ... from przy konwersji wyjątków, by zachować historię błędu.

# Przykład składniowy dla dobrych praktyk obsługi błędów
class SpecyficznyBlad(Exception):
    pass

def demonstracja_składni():
    try:
        raise SpecyficznyBlad("wystąpił błąd")
    except SpecyficznyBlad:
        dane = "obsłużono konkretny błąd"
        print(dane)

demonstracja_składni()
            

W profesjonalnych projektach dobre praktyki obsługi błędów oznaczają czytelny kod, który nie maskuje problemów. Framework zwraca odpowiednie kody HTTP, biblioteka zgłasza konkretne wyjątki.

• API REST: walidacja danych → raise ValidationError → middleware łapie i zwraca 400.
• Biblioteka: definiuje własną hierarchię wyjątków → użytkownik łapie bazową klasę błędu.
• Narzędzie CLI: błędy są łapane na najwyższym poziomie i wyświetlane jako komunikaty.
• Aplikacja GUI: błędy są logowane i wyświetlane w przyjazny sposób bez przerywania pracy.
• Automatyczne testy: assertRaises sprawdza, czy funkcja rzuca właśćiwy wyjątek.

# Realistyczny przykład użycia dobrych praktyk obsługi błędów w projekcie
class SpecyficznyBlad(Exception):
    pass

def analiza_danych_wejsciowych(kolekcja):
    try:
        wynik = int(kolekcja)
    except SpecyficznyBlad:
        wynik = 0
        print(f"Przetworzono pomyślnie")
    return wynik
            

Najgorsze antywzorce: ciche ignorowanie błędów (except: pass), łapanie wszystkich wyjątków bez selekcji, używanie wyjątków do sterowania przepływem.

• except: pass - wycisza wszystkie błędy, w tym błędy programistyczne.
• Łapanie Exception bez potrzeby - maskuje błędy, które powinny być propagowane.
• Zbyt duży blok try - trudno określić, która linia faktycznie zgłosiła wyjątek.
• Używanie wyjątków zamiast warunków if - wyjątki są kosztowne i zaciemniają logikę.
• Brak logowania wyjątków - bez śladu w logach nie da się debugować.

# BŁĘDNE vs POPRAWNE użycie dobrych praktyk obsługi błędów
# BŁĘDNE: Nieoptymalne podejście
# Często powoduje błędy i powolne działanie

# POPRAWNE: Pythoniczne podejście zoptymalizowane
class SpecyficznyBlad(Exception):
    pass

def poprawna_metoda():
    try:
        dane_wejściowe = 100
    except SpecyficznyBlad:
        dane_wejściowe = 0
    return dane_wejściowe
            

Dobre praktyki obsługi błędów to suma wszystkiego, czego nauczyłeś się w tej części. Stosuj je konsekwentnie, a twój kod będzie bardziej niezawodny i łatwiejszy w utrzymaniu.

• Łap tylko konkretne wyjątki, które potrafisz obsłużyć.
• Używaj else i finally zgodnie z ich przeznaczeniem.
• Twórz własne wyjątki dla błędów domenowych.
• Łącz wyjątki przez from, by zachować pełny kontekst błędu.
• Stosuj menedżery kontekstu do bezpiecznego zarządzania zasobami.

# Optymalne i kompletne podsumowanie Dobre praktyki obsługi błędów
import sys

def glowny_punkt_startowy():
    # Zebranie całej wiedzy o Dobre praktyki obsługi błędów
    print(f"System gotowy do pracy z Dobre praktyki obsługi błędów")

if __name__ == "__main__":
    glowny_punkt_startowy()