[z.....a]

Mirki pytonowe, jak w unittestach sprawdzić czy logger pythonowy zwrócił błąd?

Załóżmy, że mam funkcję która przyjmuje dane i w sytuacji gdy są poprawne coś tam wykonuje a gdy są błędne to robi logger.error('error nr1234'). Teraz chcę napisać test który prześle błędne dane do funkcji i sprawdzi czy został wyrzucony błąd przez loggera. jak to sprawdzić? ( ͡° ʖ̯ ͡°)

#python #programowanie

[N.....y]

@zygmunt_III_waszka: a nie możesz błędu obsłużyć od razu? Tylko wysyłać błąd z logów?

[L.....F]

@zygmunt_III_waszka: ustaw logowanie do pliku i sprawdź, czy zapisał tam błąd. Pewnie jest bardziej elegancka metoda, ale kiedyś tak zrobiłem, nawet przeszło code review :)

[a858784]

@zygmunt_III_waszka: użyj mocka

[edgar_k]

@zygmunt_III_waszka: a piszesz system do logowania, ze go testujesz?

[T.....c]

@zygmunt_III_waszka: robisz to źle, funkcja powinna rzucić wyjątek gdy coś pójdzie źle a nie wrzucać do logów. Logi możesz robić ale dodatkowo.

[z.....a]

@Teal_c:
@edgar_k: ok. W sumie racja, dzięki :*

[S.....c]

@zygmunt_III_waszka: zaimportuj sobie logger z danego modułu, mockujesz i sprawdzasz call
@Teal_c: bzdura, jak robisz apkę webową, to lepiej żeby user dostał 500tką na twarz czy ładnie zalogować błąd a usera poinformować o porażce?

[Pipcieo]

@Szarlejowiec: bzdura to ciebie wiesz. @Teal_c dobrze napisał. Jeżeli pojawi się błąd to aplikacja/wątek obsługujący usera powinien jak umrzeć i przekazać sterowanie do części odpowiedzialnej za ładne poinformowanie usera o problemie - niezależnej od części która się właśnie wywaliła. Absolutnie nie powinien tego robić błędogen. On może najwyżej zalogować, co dokładnie poszło nie tak, ale i to bez gwarancji że się uda.
To są absolutne podstawy tworzenia aplikacji robiących

[S.....c]

@Pipcieo:

try:
 something_risky()
except Exception:
 logger.error(u'something_risky

[Pipcieo]

@Szarlejowiec: Źle. Będziesz to wsadzał do każdej akcji w kontrolerze/widoku? Źle, źle, źle.
Po to masz error handlery niezależne żeby obsługiwać takie sytuacje.

[S.....c]

@Pipcieo: daj snippet jak według Ciebie powinno to wyglądać.

[laki1]

@Szarlejowiec: nie no stary powodzenia z takim pisaniem :D

[Pipcieo]

@Szarlejowiec: w aplikacji webowej? W widoka/kontrolerze odpowiedzialnych realizujących biznesową funkcjonalność żadnego postępowania z ogólnymi/niespodziewanymi błędami. Łapania wyjątków na tym etapie możesz używać do sterowania przepływem - ale wyjątków spodziewanych (duplikat nazwy użytkownika w bazie danych, file exists itp) - już nie dyskutując czy to ładne czy nie.
Co więcej, error handlery również łapią wyjątki po to żeby zrobić z nimi coś sensownego, z góry zaprojektowanego w aplikacji (wysyłka maila o

[S.....c]

@Pipcieo: mówiąc na przykładzie django, logger często konfiguruje się, żeby przesłał błąd na maila/ podpina się go do sentry, cokolwiek. Zresztą tak jak napisałem - wykonujesz coś, co wiadomo, że może się wykrzaczyć w jakiś dany sposób, łapię ten wyjątek (głupio napisałem Exception, miało być JakisException), logujesz i fallback to usera, niech to będzie nawet return handlethiserror(e)

[Pipcieo]

@Szarlejowiec: to się nie sprawdzi w dużych aplikacjach, serio. Nie dam ci przykładu w django (bo nie używam) ale na pewno to się da zrobić poprawnie. Na pierwszy rzut oka w google:
https://docs.djangoproject.com/en/1.8/topics/http/views/#customizing-error-views
http://stackoverflow.com/questions/12757856/django-exception-handler-middleware-and-handler500

[S.....c]

@Pipcieo: wszystko spoko, tego się używa, ale wydaje mi się, że ja o jednym, a Ty o czym innym :P co jest złego z zalogowaniu, że wystąpił dany error? Potem, jasne, czemu nie, można podnieść 404 czy inny error, albo bezpośrednio odesłać response. Kwestia tego co jest używane w projekcie i jaki jest design. Niektórzy wolą generyczną 500tkę, inni tą samą stronę z popupem o błędzie (django ma całkiem fajny

[Pipcieo]

@Szarlejowiec: to, że możesz nie być w stanie rzeczywiście tego błędu zalogować (bo np. się zapchał dysk) a error handler już tak (bo ten co go pisał przewidział takie rzeczy). Natomiast ty ten błąd łapiesz i próbując go zalogować w rzeczywistości go maskujesz. Error handler zaloguje... błąd logowania na wyższej warstwie nie widząc rzeczywistego błędu.
I nie, to nie jest kwestia tego kto co woli i jaki jest design. Pewne

[T.....c]

@Szarlejowiec: Funkcja rzucająca wyjątek != 500 dla usera!
Jeszcze zostaje obsługa tych błędów po stronie kontrolera danego widoku/wywołania ajax itp. itd.
I to właśnie tam ma się odbyć przekształcenie danego obiektu Exception() na coś strawnego dla usera końcowego.

[S.....c]

@Pipcieo:

@Teal_c: pracowałem już przy kilku sporych projektach, widać nie były wystarczajaco spore :) dzięki, dokształcę się

[T.....c]

@Szarlejowiec: Nie ma za co, jakby co to krzycz/wołaj i pytaj, zawsze pomogę : ).
Mam za sobą kilkanaście wdrożeń sporych biznesowych projektów webowych (takich 50k++ userów).