Best practice for using assert

Question

Is there a performance or code maintenance issue with using assert as part of the standard code instead of using it just for debugging purposes   Is  assert x  gt   0   x is less than zero    better or worse than   if x  lt  0      raise Exception   x is less than zero   Also  is there any way to set a business rule like if x  lt  0 raise error that is always checked without the try except finally so  if at anytime throughout the code x is less than 0 an error is raised  like if you set assert x  lt  0 at the start of a function  anywhere within the function where x becomes less then 0 an exception is raised

User · Answer

An Assert is to check - 1  the valid condition   2  the valid statement   3  true logic  of  source code  Instead of failing the whole project it gives an alarm that something is not appropriate in your source file   In example 1  since variable  str  is not null  So no any assert or exception get raised   Example 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   In example 2  var  str  is null  So we are saving the user from going ahead of faulty program by assert statement    Example 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   The moment we don t want debug and realized the assertion issue in the source code  Disable the optimization flag  python -O assertStatement py nothing will get print

User · Answer

Asserts should be used to test conditions that should never happen   The purpose is to crash early in the case of a corrupt program state   Exceptions should be used for errors that can conceivably happen  and you should almost always create your own Exception classes     For example  if you re writing a function to read from a configuration file into a dict  improper formatting in the file should raise a ConfigurationSyntaxError  while you can assert that you re not about to return None     In your example  if x is a value set via a user interface or from an external source  an exception is best   If x is only set by your own code in the same program  go with an assertion

User · Answer

The English language word assert here is used in the sense of swear  affirm  avow  It doesn t mean  check  or  should be   It means that you as a coder are making a sworn statement here     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   If the code is correct  barring Single-event upsets  hardware failures and such  no assert will ever fail  That is why the behaviour of the program to an end user must not be affected  Especially  an assert cannot fail even under exceptional programmatic conditions  It just doesn t ever happen  If it happens  the programmer should be zapped for it

User · Answer

assert  statements are removed when the compilation is optimized   So  yes  there are both performance and functional differences      The current code generator emits no code for an assert statement when optimization is requested at compile time  - Python 2 Docs Python 3 Docs   If you use assert to implement application functionality  then optimize the deployment to production  you will be plagued by  but-it-works-in-dev  defects   See PYTHONOPTIMIZE and -O -OO

User · Answer

Is there a performance issue    Please remember to  make it work first before you make it work fast   Very few percent of any program are usually relevant for its speed  You can always kick out or simplify an assert if it ever proves to be a performance problem -- and most of them never will  Be pragmatic  Assume you have a method that processes a non-empty list of tuples and the program logic will break if those tuples are not immutable  You should write   def mymethod listOfTuples       assert all type tp   tuple for tp in listOfTuples     This is probably fine if your lists tend to be ten entries long  but it can become a problem if they have a million entries  But rather than discarding this valuable check entirely you could  simply downgrade it to  def mymethod listOfTuples       assert type listOfTuples 0    tuple     in fact  all  must be tuples    which is cheap but will likely catch most of the actual program errors anyway

User · Answer

The four purposes of assert  Assume you work on 200 000 lines of code with four colleagues Alice  Bernd  Carl  and Daphne  They call your code  you call their code   Then assert has four roles    Inform Alice  Bernd  Carl  and Daphne what your code expects  Assume you have a method that processes a list of tuples and the program logic can break if those tuples are not immutable   def mymethod listOfTuples       assert all type tp   tuple for tp in listOfTuples     This is more trustworthy than equivalent information in the documentation and much easier to maintain  Inform the computer what your code expects  assert enforces proper behavior from the callers of your code  If your code calls Alices s and Bernd s code calls yours  then without the assert  if the program crashes in Alices code  Bernd might assume it was Alice s fault  Alice investigates and might assume it was your fault  you investigate and tell Bernd it was in fact his  Lots of work lost  With asserts  whoever gets a call wrong  they will quickly be able to see it was their fault  not yours  Alice  Bernd  and you all benefit  Saves immense amounts of time  Inform the readers of your code  including yourself  what your code has achieved at some point  Assume you have a list of entries and each of them can be clean  which is good  or it can be smorsh  trale  gullup  or twinkled  which are all not acceptable   If it s smorsh it must be unsmorshed  if it s trale it must be baludoed  if it s gullup it must be trotted  and then possibly paced  too   if it s twinkled it must be twinkled again except on Thursdays  You get the idea  It s complicated stuff  But the end result is  or ought to be  that all entries are clean  The Right Thing TM  to do is to summarize the effect of your cleaning loop as  assert all entry isClean   for entry in mylist     This statements saves a headache for everybody trying to understand what exactly it is that the wonderful loop is achieving  And the most frequent of these people will likely be yourself  Inform the computer what your code has achieved at some point  Should you ever forget to pace an entry needing it after trotting  the assert will save your day and avoid that your code breaks dear Daphne s much later    In my mind  assert s two purposes of documentation  1 and 3  and  safeguard  2 and 4  are equally valuable  Informing the people may even be more valuable than informing the computer because it can prevent the very mistakes the assert aims to catch  in case 1  and plenty of subsequent mistakes in any case

User · Answer

To be able to automatically throw an error when x become less than zero throughout the function  You can use class descriptors  Here is an example   class LessThanZeroException Exception       pass  class variable object       def   init   self  value 0           self   x   value      def   set   self  obj  value           if value  lt  0              raise LessThanZeroException  x is less than zero            self   x    value      def   get   self  obj  objType           return self   x  class MyClass object       x   variable     gt  gt  gt  m   MyClass    gt  gt  gt  m x   10  gt  gt  gt  m x -  20 Traceback  most recent call last     File   lt stdin gt    line 1  in  lt module gt    File  my py   line 7  in   set       raise LessThanZeroException  x is less than zero   LessThanZeroException  x is less than zero

User · Answer

As has been said previously  assertions should be used when your code SHOULD NOT ever reach a point  meaning there is a bug there  Probably the most useful reason I can see to use an assertion is an invariant pre postcondition  These are something that must be true at the start or end of each iteration of a loop or a function   For example  a recursive function  2 seperate functions so 1 handles bad input and the other handles bad code  cause it s hard to distinguish with recursion   This would make it obvious if I forgot to write the if statement  what had gone wrong   def SumToN n       if n  lt   0          raise ValueError   N must be greater than or equal to 0      else          return RecursiveSum n   def RecursiveSum n        precondition  n  gt   0     assert n  gt   0      if n    0          return 0     return RecursiveSum n - 1    n      postcondition  returned sum of 1 to n   These loop invariants often can be represented with an assertion

User · Answer

In addition to the other answers  asserts themselves throw exceptions  but only AssertionErrors  From a utilitarian standpoint  assertions aren t suitable for when you need fine grain control over which exceptions you catch

User · Answer

In IDE s such as PTVS  PyCharm  Wing assert isinstance   statements can be used to enable code completion for some unclear objects

User · Answer

The only thing that s really wrong with this approach is that it s hard to make a very descriptive exception using assert statements   If you re looking for the simpler syntax  remember you can also do something like this   class XLessThanZeroException Exception       pass  def CheckX x       if x  lt  0          raise XLessThanZeroException    def foo x       CheckX x       do stuff here   Another problem is that using assert for normal condition-checking is that it makes it difficult to disable the debugging asserts using the -O flag

User · Answer

Both the use of assert and the raising of exceptions are about communication    Assertions are statements about the correctness of code addressed at developers  An assertion in the code informs readers of the code about conditions that have to be fulfilled for the code being correct   An assertion that fails at run-time informs developers that there is a defect in the code that needs fixing  Exceptions are indications about non-typical situations that can occur at run-time but can not be resolved by the code at hand  addressed at the calling code to be handled there   The occurence of an exception does not indicate that there is a bug in the code       Best practice   Therefore  if you consider the occurence of a specific situation at run-time as a bug that you would like to inform the developers about   Hi developer  this condition indicates that there is a bug somewhere  please fix the code    then go for an assertion   If the assertion checks input arguments of your code  you should typically add to the documentation that your code has  undefined behaviour  when the input arguments violate that conditions   If instead the occurrence of that very situation is not an indication of a bug in your eyes  but instead a  maybe rare but  possible situation that you think should rather be handled by the client code  raise an exception   The situations when which exception is raised should be part of the documentation of the respective code      Is there a performance       issue with using assert   The evaluation of assertions takes some time   They can be eliminated at compile time  though   This has some consequences  however  see below      Is there a       code maintenance issue with using assert   Normally assertions improve the maintainability of the code  since they improve readability by making assumptions explicit and during run-time regularly verifying these assumptions   This will also help catching regressions   There is one issue  however  that needs to be kept in mind  Expressions used in assertions should have no side-effects   As mentioned above  assertions can be eliminated at compile time - which means that also the potential side-effects would disappear   This can - unintendedly - change the behaviour of the code

User · Answer

Well  this is an open question  and I have two aspects that I want to touch on  when to add assertions and how to write the error messages   Purpose  To explain it to a beginner - assertions are statements which can raise errors  but you won t be catching them  And they normally should not be raised  but in real life they sometimes do get raised anyway  And this is a serious situation  which the code cannot recover from  what we call a  fatal error    Next  it s for  debugging purposes   which  while correct  sounds very dismissive  I like the  declaring invariants  which should never be violated  formulation better  although it works differently on different beginners    Some  just get it   and others either don t find any use for it  or replace normal exceptions  or even control flow with it   Style  In Python  assert is a statement  not a function   remember assert False   is true   will not raise  But  having that out of the way   When  and how  to write the optional  error message    This acually applies to unit testing frameworks  which often have many dedicated methods to do assertions  assertTrue condition   assertFalse condition   assertEqual actual  expected  etc    They often also provide a way to comment on the assertion   In throw-away code you could do without the error messages   In some cases  there is nothing to add to the assertion   def dump something          assert isinstance something  Dumpable                But apart from that  a message is useful for communication with other programmers  which are sometimes interactive users of your code  e g  in Ipython Jupyter etc     Give them information  not just leak internal implementation details   instead of   assert meaningless identifier  lt   MAGIC NUMBER XXX   meaningless identifier is greater than MAGIC NUMBER XXX       write   assert meaningless identifier  gt  MAGIC NUMBER XXX   reactor temperature above critical threshold    or maybe even   assert meaningless identifier  gt  MAGIC NUMBER XXX  f reactor temperature  meaningless identifier    above critical threshold   MAGIC NUMBER XXX      I know  I know - this is not a case for a static assertion  but I want to point to the informational value of the message   Negative or positive message   This may be conroversial  but it hurts me to read things like   assert a    b   a is not equal to b     these are two contradictory things written next to eachother  So whenever I have an influence on the codebase  I push for specifying what we want  by using extra verbs like  must  and  should   and not to say what we don t want   assert a    b   a must be equal to b    Then  getting AssertionError  a must be equal to b is also readable  and the statement looks logical in code  Also  you can get something out of it without reading the traceback  which can sometimes not even be available

User · Answer

For what it s worth  if you re dealing with code which relies on assert to function properly  then adding the following code will ensure that asserts are enabled   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

[python] Best practice for using assert?

Examples related to python

Examples related to assert

Examples related to assertion

Examples related to raise