1. Czy występuje problem z wydajnością lub obsługą kodu związany z używaniem assertjako części standardowego kodu zamiast używania go wyłącznie do celów debugowania?

   Jest

   assert x >= 0, 'x is less than zero'

   lepszy czy gorszy niż

   if x < 0:
       raise Exception, 'x is less than zero'

2. Czy istnieje też sposób na ustawienie reguły biznesowej, takiej jak if x < 0 raise error która jest zawsze sprawdzana bez tego try/except/finally, jeśli w dowolnym momencie w całym kodzie xjest mniejszy niż 0, zgłaszany jest błąd, np. Jeśli ustawi się assert x < 0na początku funkcji, w dowolnym miejscu funkcji gdzie xstaje się mniejszy niż 0 zgłaszany jest wyjątek?

Aby móc automatycznie zgłaszać błąd, gdy x staje się mniejszy od zera w trakcie funkcji. Możesz użyć deskryptorów klas . Oto przykład:

class LessThanZeroException(Exception):
    pass

class variable(object):
    def __init__(self, value=0):
        self.__x = value

    def __set__(self, obj, value):
        if value < 0:
            raise LessThanZeroException('x is less than zero')

        self.__x  = value

    def __get__(self, obj, objType):
        return self.__x

class MyClass(object):
    x = variable()

>>> m = MyClass()
>>> m.x = 10
>>> m.x -= 20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "my.py", line 7, in __set__
    raise LessThanZeroException('x is less than zero')
LessThanZeroException: x is less than zero

Aserty należy stosować do testowania warunków, które nigdy nie powinny się zdarzyć . Celem jest wczesne zawieszenie się w przypadku uszkodzonego stanu programu.

W przypadku błędów, które mogą się zdarzyć, należy stosować wyjątki i prawie zawsze należy tworzyć własne klasy wyjątków .

Na przykład, jeśli piszesz funkcję do odczytu z pliku konfiguracyjnego do pliku dict, niewłaściwe formatowanie w pliku powinno wywołać a ConfigurationSyntaxError, podczas gdy możesz, assertże nie masz zamiaru wrócić None.

W twoim przykładzie, jeśli xwartość jest ustawiona przez interfejs użytkownika lub ze źródła zewnętrznego, najlepszy jest wyjątek.

Jeśli xjest ustawiony tylko przez własny kod w tym samym programie, przejdź z asercją.

Instrukcje „asert” są usuwane, gdy kompilacja jest zoptymalizowana . Tak, istnieją różnice zarówno wydajnościowe, jak i funkcjonalne.

Bieżący generator kodu nie emituje kodu dla instrukcji assert, gdy wymagana jest optymalizacja w czasie kompilacji. - Python 2 Docs Python 3 Docs

Jeśli użyjesz assert do zaimplementowania funkcji aplikacji, a następnie zoptymalizuj wdrożenie do produkcji, będziesz nękany przez defekty typu „ale to działa”.

Zobacz PYTHONOPTIMIZE i -O -OO

Cztery cele assert

Załóżmy, że pracujesz nad 200 000 wierszy kodu z czterema kolegami Alice, Berndem, Carlem i Daphne. Wzywają twój kod, ty wołasz ich kod.

Następnie assertma cztery role :

1. Poinformuj Alice, Bernd, Carl i Daphne, czego oczekuje Twój kod.
   Załóżmy, że masz metodę, która przetwarza listę krotek, a logika programu może się zepsuć, jeśli krotki te są niezmienne:

   def mymethod(listOfTuples):
       assert(all(type(tp)==tuple for tp in listOfTuples))

   Jest to bardziej wiarygodne niż równoważne informacje w dokumentacji i znacznie łatwiejsze w utrzymaniu.

2. Poinformuj komputer, czego oczekuje Twój kod.
   assertwymusza prawidłowe zachowanie wywołujących kod. Jeśli twój kod wywołuje kod Alices, a kod Bernda wywołuje twój, to bez tego assert, jeśli program ulegnie awarii w kodzie Alices, Bernd może założyć, że to wina Alice, Alice bada i może założyć, że to twoja wina, zbadaj i powiedz Berndowi, że tak naprawdę jego. Dużo straconej pracy.
   Dzięki zapewnieniom, ktokolwiek pomyli połączenie, szybko zobaczy, że to ich wina, a nie twoja. Alice, Bernd i wszyscy korzystacie. Oszczędza ogromną ilość czasu.

3. Poinformuj czytelników o swoim kodzie (w tym o sobie), co osiągnął Twój kod w pewnym momencie.
   Załóżmy, że masz listę wpisów, a każdy z nich może być czysty (co jest dobre) lub może być smorsh, trale, gullup lub migotać (które wszystkie są niedopuszczalne). Jeśli jest śmierdzący, należy go niesmakować; jeśli jest to prawda, musi być baludoed; jeśli jest to mewa, należy ją wykończyć (a następnie prawdopodobnie również przyspieszyć); jeśli jest migotliwy, musi być ponownie błyśnięty, z wyjątkiem czwartków. Masz pomysł: to skomplikowane rzeczy. Ale końcowym rezultatem jest (lub powinno być), że wszystkie wpisy są czyste. Właściwą rzeczą do zrobienia jest podsumowanie efektu pętli czyszczącej jako

   assert(all(entry.isClean() for entry in mylist))

   To stwierdzenie oszczędza bólu głowy wszystkim, którzy próbują zrozumieć, co dokładnie osiąga wspaniała pętla. A najczęstszą z tych osób będzie prawdopodobnie ty.

4. Poinformuj komputer, co osiągnął Twój kod w pewnym momencie.
   Jeśli kiedykolwiek zapomnisz wkroczyć do wpisu wymagającego tego po kłusie, assertzaoszczędzi ci dzień i uniknie złamania kodu, drogi Daphne, znacznie później.

Moim zdaniem assertdwa cele dokumentacji (1 i 3) oraz zabezpieczenia (2 i 4) są równie cenne.
Informowanie ludzi może być nawet bardziej wartościowe niż informowanie komputera, ponieważ może zapobiec błędom, które assertcel ma złapać (w przypadku 1) i wielu późniejszym błędom.

Oprócz innych odpowiedzi twierdzi, że zgłaszają wyjątki, ale tylko błędy AssertionErrors. Z utylitarnego punktu widzenia twierdzenia nie są odpowiednie, gdy potrzebna jest drobnoziarnista kontrola nad tym, które wyjątki wychwytujesz.

Jedyną rzeczą, która jest naprawdę błędna w tym podejściu, jest to, że trudno jest zrobić bardzo opisowy wyjątek za pomocą instrukcji aser. Jeśli szukasz prostszej składni, pamiętaj, że możesz również zrobić coś takiego:

class XLessThanZeroException(Exception):
    pass

def CheckX(x):
    if x < 0:
        raise XLessThanZeroException()

def foo(x):
    CheckX(x)
    #do stuff here

Innym problemem jest to, że użycie aser do normalnego sprawdzania warunków powoduje, że utrudnienie wyłączenia asercji debugowania odbywa się za pomocą flagi -O.

Angielskie słowo aser tutaj jest używane w znaczeniu przekleństwa , afirmacji , avow . Nie oznacza to „sprawdź” ani „powinno być” . Oznacza to, że jako programista składasz tutaj oświadczenie pod przysięgą :

# I solemnly swear that here I will tell the truth, the whole truth, 
# and nothing but the truth, under pains and penalties of perjury, so help me FSM
assert answer == 42

Jeśli kod jest poprawny, wykluczając zdenerwowanie pojedynczego zdarzenia , awarie sprzętowe itp., Żadne potwierdzenie nigdy nie zawiedzie . Dlatego nie można wpływać na zachowanie programu dla użytkownika końcowego. Szczególnie twierdzenie nie może zawieść nawet w wyjątkowych warunkach programowych . To się po prostu nigdy nie zdarza. Jeśli tak się stanie, programista powinien zostać za to przełączony.

Jak już powiedziano wcześniej, należy stosować twierdzenia, gdy kod NIE POWINIEN nigdy osiągnąć punktu, co oznacza, że ​​jest tam błąd. Prawdopodobnie najbardziej użytecznym powodem, dla którego widzę użycie asercji, jest niezmiennik / stan wstępny / postwarunek. Są to coś, co musi być prawdziwe na początku lub na końcu każdej iteracji pętli lub funkcji.

Na przykład funkcja rekurencyjna (2 oddzielne funkcje, więc 1 obsługuje nieprawidłowe dane wejściowe, a druga obsługuje zły kod, ponieważ trudno jest odróżnić rekurencję). Byłoby to oczywiste, gdybym zapomniał napisać instrukcję if, co poszło nie tak.

def SumToN(n):
    if n <= 0:
        raise ValueError, "N must be greater than or equal to 0"
    else:
        return RecursiveSum(n)

def RecursiveSum(n):
    #precondition: n >= 0
    assert(n >= 0)
    if n == 0:
        return 0
    return RecursiveSum(n - 1) + n
    #postcondition: returned sum of 1 to n

Te niezmienniki pętli często można przedstawić za pomocą asercji.

Czy występuje problem z wydajnością?

• Pamiętaj, aby „sprawić, by działał pierwszy, zanim sprawisz, że będzie działał szybko” .
  Bardzo niewiele procent jakiegokolwiek programu jest zwykle istotne dla jego prędkości. Zawsze możesz wykopać lub uprościć, assertjeśli okaże się to problemem z wydajnością - i większość z nich nigdy nie będzie.

• Bądź pragmatyczny :
  Załóżmy, że masz metodę, która przetwarza niepustą listę krotek, a logika programu ulegnie awarii, jeśli krotki te nie będą niezmienne. Powinieneś napisać:

  def mymethod(listOfTuples):
      assert(all(type(tp)==tuple for tp in listOfTuples))

  Prawdopodobnie jest to w porządku, jeśli twoje listy mają zwykle dziesięć wpisów, ale może to stanowić problem, jeśli mają milion wpisów. Ale zamiast całkowicie odrzucić ten cenny czek, możesz po prostu obniżyć go do poziomu

  def mymethod(listOfTuples):
      assert(type(listOfTuples[0])==tuple)  # in fact _all_ must be tuples!

  co jest tanie, ale prawdopodobnie i tak złapie większość faktycznych błędów programu.

Cóż, jest to pytanie otwarte i mam dwa aspekty, które chcę dotknąć: kiedy dodawać twierdzenia i jak pisać komunikaty o błędach.

Cel, powód

Aby wytłumaczyć to początkującym - twierdzenia są stwierdzeniami, które mogą wywoływać błędy, ale ich nie złapiecie. I zwykle nie należy ich wychowywać, ale w rzeczywistości czasami i tak się wychowują. Jest to poważna sytuacja, z której kod nie może się zregenerować, co nazywamy „fatalnym błędem”.

Następnie służy do „celów debugowania”, co, choć poprawne, wydaje się bardzo lekceważące. Podoba mi się sformułowanie „deklarowanie niezmienników, które nigdy nie powinno być naruszane”, chociaż działa inaczej na różnych początkujących ... Niektórzy „po prostu to rozumieją”, a inni albo nie znajdują zastosowania, albo zastępują normalne wyjątki, a nawet kontrolować przepływ za jego pomocą.

Styl

W Pythonie assertjest instrukcją, a nie funkcją! (pamiętajcie, assert(False, 'is true')że nie podniesie. Ale odsuwając to na bok:

Kiedy i jak napisać opcjonalny „komunikat o błędzie”?

Ten acually dotyczy testów jednostkowych ram, które często mają wiele dedykowanych metod zrobić twierdzeń ( assertTrue(condition), assertFalse(condition), assertEqual(actual, expected)etc.). Często stanowią również sposób skomentowania tego twierdzenia.

W kodzie wyrzucającym można obejść się bez komunikatów o błędach.

W niektórych przypadkach do twierdzenia nie można nic dodać:

def dump (coś): assert isinstance (coś, Dumpable) # ...

Ale poza tym wiadomość jest przydatna do komunikacji z innymi programistami (którzy czasami są interaktywnymi użytkownikami twojego kodu, np. W Ipython / Jupyter itp.).

Podaj im informacje, a nie tylko wyciek wewnętrzne szczegóły implementacji.

zamiast:

assert meaningless_identifier <= MAGIC_NUMBER_XXX, 'meaningless_identifier is greater than MAGIC_NUMBER_XXX!!!'

pisać:

assert meaningless_identifier > MAGIC_NUMBER_XXX, 'reactor temperature above critical threshold'

a może nawet:

assert meaningless_identifier > MAGIC_NUMBER_XXX, f'reactor temperature({meaningless_identifier }) above critical threshold ({MAGIC_NUMBER_XXX})'

Wiem, wiem - nie dotyczy to twierdzenia statycznego, ale chcę wskazać wartość informacyjną wiadomości.

Wiadomość negatywna czy pozytywna?

Może to być kontrowersyjne, ale boli mnie czytanie takich rzeczy:

assert a == b, 'a is not equal to b'

• są to dwie sprzeczne rzeczy napisane obok siebie. Więc ilekroć mam wpływ na bazę kodu, naciskam na określenie tego, czego chcemy, używając dodatkowych czasowników, takich jak „musi” i „powinien”, a nie mówiąc, czego nie chcemy.

  twierdzić a == b, „a musi być równe b”

Następnie pobieranie AssertionError: a must be equal to bjest również czytelne, a instrukcja wygląda logicznie w kodzie. Ponadto możesz coś z niego wyciągnąć bez czytania śledzenia (które czasami może nawet nie być dostępne).

Zarówno stosowanie, jak asserti zgłaszanie wyjątków dotyczy komunikacji.

• Asercje to stwierdzenia o poprawności kodu skierowane do programistów : asercja w kodzie informuje czytelników kodu o warunkach, które muszą zostać spełnione, aby kod był poprawny. Asercja, która nie powiedzie się w czasie wykonywania, informuje programistów, że w kodzie występuje usterka wymagająca naprawy.

• Wyjątki stanowią wskazówki dotyczące nietypowych sytuacji, które mogą wystąpić w czasie wykonywania, ale nie mogą być rozwiązane przez dany kod, skierowane do obsługiwanego tam kodu wywołującego. Wystąpienie wyjątku nie oznacza, że ​​w kodzie jest błąd.

Najlepsze praktyki

Dlatego jeśli uważasz, że wystąpienie określonej sytuacji w czasie wykonywania jest błędem, o którym chciałbyś poinformować programistów („Cześć programisto, ten warunek wskazuje, że gdzieś jest błąd, proszę naprawić kod”.) idź po stwierdzenie. Jeśli asercja sprawdza argumenty wejściowe twojego kodu, zwykle powinieneś dodać do dokumentacji, że twój kod ma „niezdefiniowane zachowanie”, gdy argumenty wejściowe naruszają te warunki.

Jeśli zamiast tego wystąpienie tej samej sytuacji nie jest oznaką błędu w twoich oczach, ale zamiast tego (być może rzadką, ale) możliwą sytuacją, którą Twoim zdaniem powinien zająć się kod klienta, podnieś wyjątek. Sytuacje, w których zgłaszany jest wyjątek, powinny stanowić część dokumentacji odpowiedniego kodu.

Czy występuje problem z wydajnością [...] podczas używania assert

Ocena twierdzeń zajmuje trochę czasu. Można je jednak wyeliminować podczas kompilacji. Ma to jednak pewne konsekwencje, patrz poniżej.

Czy podczas korzystania z [...] występuje problem z konserwacją kodu? assert

Zwykle asercje poprawiają łatwość konserwacji kodu, ponieważ poprawiają czytelność poprzez wyraźne przyjmowanie założeń i regularne ich weryfikowanie w czasie wykonywania. Pomoże to również w łapaniu regresji. Należy jednak pamiętać o jednej kwestii: wyrażenia użyte w asercjach nie powinny mieć skutków ubocznych. Jak wspomniano powyżej, twierdzenia można wyeliminować w czasie kompilacji - co oznacza, że ​​znikną również potencjalne skutki uboczne. Może to - niezamierzenie - zmienić zachowanie kodu.

Assert ma sprawdzić -
1. poprawny warunek,
2. poprawną instrukcję,
3. prawdziwą logikę;
kodu źródłowego. Zamiast zawieść cały projekt, alarmuje, że coś nie jest odpowiednie w twoim pliku źródłowym.

W przykładzie 1, ponieważ zmienna „str” nie ma wartości null. Więc żadne zgłoszenie ani wyjątek nie zostaną zgłoszone.

Przykład 1:

#!/usr/bin/python

str = 'hello Python!'
strNull = 'string is Null'

if __debug__:
    if not str: raise AssertionError(strNull)
print str

if __debug__:
    print 'FileName '.ljust(30,'.'),(__name__)
    print 'FilePath '.ljust(30,'.'),(__file__)


------------------------------------------------------

Output:
hello Python!
FileName ..................... hello
FilePath ..................... C:/Python\hello.py

W przykładzie 2 var 'str' ma wartość NULL. Tak więc ratujemy użytkownika przed pójściem dalej od wadliwego programu za pomocą instrukcji assert .

Przykład 2:

#!/usr/bin/python

str = ''
strNull = 'NULL String'

if __debug__:
    if not str: raise AssertionError(strNull)
print str

if __debug__:
    print 'FileName '.ljust(30,'.'),(__name__)
    print 'FilePath '.ljust(30,'.'),(__file__)


------------------------------------------------------

Output:
AssertionError: NULL String

W chwili, gdy nie chcemy debugować i zdajemy sobie sprawę z problemu asercji w kodzie źródłowym. Wyłącz flagę optymalizacji

python -O assertStatement.py
nic nie zostanie wydrukowane

W IDE, takich jak PTVS, PyCharm, assert isinstance()można używać instrukcji Wing, aby umożliwić uzupełnianie kodu dla niektórych niejasnych obiektów.

Jeśli chodzi o to, co warto, jeśli masz do czynienia z kodem, który polega na assertpoprawnym działaniu, dodanie następującego kodu zapewni włączenie asercji:

try:
    assert False
    raise Exception('Python assertions are not working. This tool relies on Python assertions to do its job. Possible causes are running with the "-O" flag or running a precompiled (".pyo" or ".pyc") module.')
except AssertionError:
    pass