I love assert

[Anton]

On Wednesday, November 12, 2014 2:05:17 PM UTC-8, Ian wrote:
> On Wed, Nov 12, 2014 at 2:56 PM, Marko Rauhamaa wrote:
> > Ethan Furman:
> >
> >> On 11/12/2014 01:41 PM, Marko Rauhamaa wrote:
> >>>
> >>> Or I might indicate the exhaustion of possibilities:
> >>>
> >>>       if status == OK:
> >>>           ...
> >>>       elif status == ERROR:
> >>>           ...
> >>>       else:
> >>>           assert status == WARNING
> >>>           ...
> >>
> >> And here's a nice example of what one should NOT do. Imagine that a
> >> new status, CONFUSED is added, the above code is not modified to
> >> handle it, and for whatever reason the program is being run optimized
> >> -- the assert is not there, and CONFUSED is treated the same as
> >> WARNING.
> >
> > How would it be better if you removed the assert then?
> 
> You don't need to remove it. Just reorganize it to make sure it
> indicates actual exhaustion of possibilities. E.g. using the "assert
> False" pattern from your post:
> 
> if status == OK:
>     ...
> elif status == ERROR:
>     ...
> elif status == WARNING:
>     ...
> else:
>     assert False

If the code is run optimized and asserts are ignore CONFUSED statement would still not be handled and you will not know about it.
I would do something like:

if status == OK:
    ...
elif status == ERROR:
    ...
elif status == WARNING:
    ...
else:
    raise RuntimeError("Unknown errorno")

Or if it is at the end of the function, then:

if status == OK:
    ...
elif status == ERROR:
    ...
elif status == WARNING:
    ...

raise RuntimeError("Unknown errorno")

unless there is a customer exception type I can use for this situation.