On 3/12/21 8:58 AM, Chris Angelico wrote: > On Sat, Mar 13, 2021 at 12:11 AM Richard Damon <rich...@damon-family.org> > wrote: >> On 3/12/21 12:31 AM, Chris Angelico wrote: >>> On Fri, Mar 12, 2021 at 3:53 PM Cameron Simpson <c...@cskk.id.au> wrote: >>>> For me, try/except is for when something might reasonably "go wrong" in >>>> normal use, even niche normal use. Whereas assert is for things which >>>> should _never_ occur. Roughly, again for me, try/except if for catching >>>> misuse and assert is for catching misdesign/misimplementation. >>> Something like that, yeah. An assertion failure represents a bug *in >>> this code*, something that shouldn't ever happen. If it's possible to >>> trigger the failure with some other piece of code (calling something >>> with bad arguments, or whatever), then assert is the wrong tool for >>> the job. Similarly, if you find yourself catching AssertionError >>> anywhere outside of unit testing, something is horribly wrong >>> somewhere :) >>> >>> ChrisA >> Chris, I would disagree with that statement. An assert says that there >> is something wrong with THE code, not THIS code. It is perfectly >> reasonable, and good defensive programming, to assert on the >> per-conditions to the procedure at its beginning. >> >> Now, it may be true that a 'friendlier' procedure may be defined to >> check some of these and return an error, but that then locks that >> behavior into the API, so the cost of the check becomes an absolute >> requirement. >> > It's perfectly reasonable to put "if condition: raise Blah", but is it > really reasonable to use the assert statement, which (a) might not be > run, and (b) raises a very generic exception? Make assertions about > your own code, not other people's. > > ChrisA
My issue with that is that I feel that if the program raises an exception, if SHOULD document what exceptions it raises and under what conditions. That means that the detection of bad parameters has now been moved from being an 'improper' use of the module, to being defined to be checked for, and thus now a required part of the API. Exceptions are designed for errors that might be correctable by outer layers, program errors that you catch with assert tend not to fall into that category. Asserts indicate that there is a programming error that has been detected, and the operation should be aborted. The exception generated will not be used to 'correct' the error, but might reformat the assert message and facilitate its reporting, or for an interactive program, perhaps provide a path for the user to save his work or work around the program bug. The are conceptually very different sorts of things, and should not be interchanged. Note, it is often hard to tell if the 'impossible' state you ended up in is truly a fault with your own code or the code that is calling you, so often the detecting of bad parameters is really akin to detecting your routine has gotten into a state it should not be in, the only difference is you have detected this before you have done anything, and thus help locate where the bug is. -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
