Django, except IntegrityError

Jeden mały, niewinny szczeniaczek o maślanych oczkach zostaje gdzieś na świecie żywcem przemielony na karmę dla kotów za każdym razem, kiedy piszesz coś takiego:

try:
    # ...
except IntegrityError:
    return None

Łapanie IntegrityError jako metoda wykrywania problemów jest równie dobrym pomysłem, co wymiana czujników dymu na urządzenie wykrywające odgłos syreny nadjeżdżającej straży pożarnej.

Błąd na poziomie bazy danych jest nieodwracalny. Nie można nic naprawić. To jak pójść pośmiertnie do lekarza. Połknięcie wyjątku bez dalszej propagacji to tylko dodatkowe punkty za styl. Dzięki temu wszystkie otwarte transakcje (z izolującą włącznie) właśnie stały się bezużyteczne, a najbliższa operacja na bazie danych spowoduje spektakularny zgon całej aplikacji.

Wersja obrazowa

Twój kod próbuje dywanikiem z kibla gasić ogień w domu, w którym dawno złuszczyły się tapety i zniknęły meble. W domu, który sam podpalił. Niezbyt zadowolony z rezultatów wychodzi więc przed budynek i dusi strażaków wężem. Po wszystkim, gwiżdżąc, z rękoma w kieszeniach, odchodzi w stronę zachodzącego słońca, po drodze mijając sąsiada — powoli spopielającego się we własnym ogródku.

5 myśli nt. „Django, except IntegrityError

  1. Bardziej ogólnie to except: pass i except Exception:pass to w 90% przypadków bardzo zły pomysł (ogólnie w programowaniu). Co do reszty się zgadzam (nawet sam w amoku coś takiego napisałem). Bez porządnego tdd praca z czymś takim to koszmar. Zastanawiałem się kiedyś z czego to wynika. W Java/C++ (śmiech na bok) w dokumentacjach api projektów częściej widziałem wyjątki jakie wypluwa dana metoda, a w pythonie (projektach, środowisku) jest z tym słabo/średnio/bez spojrzenia w kod nie ustalisz.
    Mimo tego że dokumentacja architektury/zachowań zazwyczaj jest naprawdę przystępna ;]
    btw. dla mnie IntegrityError to taki Unicorn który pojawia się rzadko i zwiastuje że nie wykonałem migracji ;)

  2. ps 1. Taki (częściowo powiązany) antywzorzec rzucania wyjątków to robienie biblioteki i na każdy błąd dawanie raise BigMothaFuckaException(‘opis bledu’) bez podziału na konkretne przypadki.
    Potem użytkownicy się śmieją że dajesz Message “wystąpił bliżej nieokreślony błąd” ;) albo @fijal smieje się że łapiąc exception “grepujesz” po jego message aby ustalić co się stało :)

  3. Dramatyzujesz. Prawda jest taka, że można reinicjować bazę. Nawiązać ponowne połączenie, ew. z opóźnieniem i nadpisać stary obiekt obsługi bazy. Trochę zabawy z tym jest, bo musisz wszystkie pierdółki od razu zresetować, ale to fajna zabawa. ;)

  4. Cholera, zabiłem szczeniaczka… Nie możesz zmienić na ‘kotka o maślanych oczkach’, miałbym spokojniejsze sumienie!

    Pozdro,
    majki

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć następujących tagów oraz atrybutów HTML-a: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>