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.
--
https://mail.python.org/mailman/listinfo/python-list
