JajkoJajkoJajkoJajko
JajkoJajkoJajkoJajko
#naukaprogramowania #programowanie #python

czy taki sposób radzenia sobie z wyjątkami jak w tym fragmencie kodu jest poprawny? sprawdziłem kilka innych sposobów i ten obliczeniowo jest najszybszy, poza tym wydaje się najbardziej klarowny. Ale czy, hmm, zgodny z ogólnie przyjętą 'konwencją'?

nawiasem mówiąc - piszę sobie w ramach nauki bibliotekę pozwalającą na lepszą współpracę biblioteki pandas z bazą postgresql. jak skończę to chętnie się podzielę.
  • Najlepsze
  • Wszystkie komentarze
A.....t
A.....t
@JajkoJajkoJajkoJajko: bo chodzi o to, że w except masz łapać błędy, a nie rzucać
A.....t
A.....t
@JajkoJajkoJajkoJajko: wyjątki zamiast ifów? xd
A.....t
A.....t
@JajkoJajkoJajkoJajko: nie znam pythona, ale nie podoba mi się to
JajkoJajkoJajkoJajko
JajkoJajkoJajkoJajko
@Kiro: dokładnie tak robiłem wcześniej, komentarz wyżej napisałem sposób postępowania. Czyli wcześniejsze rozwiązanie, które już miałem, jest prawidłowe tylko za bardzo chciałem przykombinować :) dzięki za pomoc
JajkoJajkoJajkoJajko
JajkoJajkoJajkoJajko
@biwalencik: tego nie kojarze, ale tutaj jak na szybko przejrzałem dokumentację to też nie widzę np. możliwości aktualizowania rekordów po kluczu głównym. Pozostanę raczej przy napisaniu swojej skromnej biblioteki, dodatkowo pewnie sporo się przy tym nauczę :) Ale dzięk iza wszystkie rady, zarówno Tobie jak i @Kiro:
JajkoJajkoJajkoJajko
JajkoJajkoJajkoJajko
@AwizisieAkat: Gdzieś przeczytałem coś w stylu, że w przypadku wyrzucania wyjątków powinno się unikać ifów. a co gdyby tych ifów było jeszcze więcej niż w przypadku mojego kodu? wtedy nawet takie rozrośnięte drzewo jest ok?
JajkoJajkoJajkoJajko
JajkoJajkoJajkoJajko
@AwizisieAkat: zresztą zanim wrzuciłem to na pastebina to nie przetestowałem, a teraz sprawdziłem i jak chcę jakiś wyjątek wyrzucić to wywala mi zupełnie inny :P także powyższy sposób i tak nie działa poprawnie
biwalencik
@JajkoJajkoJajkoJajko: pozamykaj komunikację z bazą danych w fukcjach albo klasach i albo napisz wlasne wyjatki, albo bazuj na tych, ktore wyrzuca python.
Kiro
Kiro
0
@JajkoJajkoJajkoJajko: Przecież to nie ma prawa zadziałać, jak faktycznie poleci tam wyjątek, to zamiast złapania go, dostaniesz TypeError. To co co chciałeś zrobić, powinieneś zrobić inaczej, najprościej ifami, a co do wyjątków to proponuję przeczytać co to w ogóle jest, bo podchodzisz do tego od złej strony
JajkoJajkoJajkoJajko
JajkoJajkoJajkoJajko
@biwalencik: Dokładnie to robię. chciałbym tylko konkretnie określić co jest nie tak, czyli np błędną nazwę tabeli lub schematu i nie wiem czy rzeczywiście sprawdzać wszystko ifami, czy raczej excepty trzaskać. Jak jest poprawnie w pythonie?
biwalencik
@JajkoJajkoJajkoJajko: Masz wybor w ifie tez musisz a\akos oblsuzyc falszywy warunek. Najgorzej puscic go samopas poprzez pass. Mozesz po ifie zrobic jakis log.error, zalezy od krytycznosci komponentu. Mozesz napisac wlasny wyjatek i go obsluzyc, ale z reguly bedziesz i tak tworzyl subklasy do istniejacych juz wyjatkow systemowych (brak pliku, zla wartosc etc), wiec najlatwiej bedzie zobaczyc co sie dzieje jak podasz cos zle i jaki wyjatek wyrzuca python i
Kiro
Kiro
0
Gdzieś przeczytałem coś w stylu, że w przypadku wyrzucania wyjątków powinno się unikać ifów.


@JajkoJajkoJajkoJajko: W przypadku łapania bardziej, żeby rzucić wyjątek, zazwyczaj musi zajść ku temu jakiś warunek, czyli musisz coś sprawdzić. Np. że nazwa tabeli jest nieprawidłowa. A jeśli zaczyna Ci się robić brzydkie drzewko, to musisz, tak jak napisał ktoś wyżej, wynieść wszelkie sprawdzenia do np. osobnych funkcji.
Łapiąc wyjątek, w exceptcie musisz podać jakiego TYPU wyjątek
JajkoJajkoJajkoJajko
JajkoJajkoJajkoJajko
@biwalencik: rozumiem o co chodzi. Na tym poziomie chciałbym, żeby funkcja w razie niepoprawnej akcji wyrzucała wyjątek, dopiero później, przy korzystaniu z funkcji zeby ewentualnie wyłapywac go za pomocą try/except. ale ok, już rozumiem

@Kiro: o właśnie, wcześniej robiłem własnie osobne funkcje do sprawdzania i za ich pomocą wyrzucałem wyjątki, coś w takiego:

def schema
biwalencik
@JajkoJajkoJajkoJajko: Za bardzo kombinujesz.

Masz def schemacostam(), ktory cos zwraca. zrob try schemacostam i lab wyjatek za pomoca ecxcept. Np:

def
Kiro
Kiro
0
@JajkoJajkoJajkoJajko: Tak, dokładnie tak, z tym że możesz te sprawdzenia wynieść do innej funkcji, którą wywołąsz na początku get_table_pk
JajkoJajkoJajkoJajko
JajkoJajkoJajkoJajko
@biwalencik: ta funkcja schemaerrorraiser służy stricte do wyłapywania wyjątków. więc tą funkcję chcę wrzucić do funkcji, którą zamieściłem w pastebin (gettablepk). a następnie ją wywołać wywoływać:

try:
___gettablepk(table, schema)
except ValueError as e:
___logger.error(e)
biwalencik
@JajkoJajkoJajkoJajko: Mysle, ze wywarzasz otwarte drzwi. Do komunikacji z bazami jest tyle standardowych pakietow. Moze MUSISZ napisac to sam, ale jesli nie musisz zajzyj na SQLAlchemy, ponyORM, albo cos podobnego.
Kiro
Kiro
0
Mysle, ze wywarzasz otwarte drzwi. Do komunikacji z bazami jest tyle standardowych pakietow. Moze MUSISZ napisac to sam, ale jesli nie musisz zajzyj na SQLAlchemy, ponyORM, albo cos podobnego


@biwalencik: Bez przesady, kolega się uczy, jaki jest sens używać ORMów kiedy nie wie się co one w sumie robią? Później masz całe stada programistów którzy klepią modele w django i nie rozumieją skąd w sumie te dane się tam biorą,
biwalencik
@Kiro: Moze sie uczy, moze musi na jutro miec cos w bazie. ORM moze pomoc
Kiro
Kiro
0
Moze sie uczy, moze musi na jutro miec cos w bazie. ORM moze pomoc


@biwalencik: Jak i zaszkodzić :)