Returning within a finally block can be surprising since the finally
block will "hijack" the regular return flow. In this case, pylint is
trying to warn us that the return-within-finally would discard the
earlier caught exception. For this particular function we don't care
that the exception is lost, so the existing code is correct but possibly
confusing.
Our options are:
1. Disable the lost-exception warning for this function
2. Rewrite the function to avoid return-within-finally
This change takes approach (2), since the required change is trivial.
This change also enables the corresponding pylint check now that the
only offending case has been removed.
Change-Id: If1706851b4bd67ebdbbdb3485984773598efdf7a
global-statement,
global-variable-not-assigned,
logging-not-lazy,
- lost-exception,
no-init,
non-parent-init-called,
pointless-string-statement,
def _validate_mac_address(data, valid_values=None):
- valid_mac = False
try:
valid_mac = netaddr.valid_mac(_validate_no_whitespace(data))
except Exception:
- pass
- finally:
- # TODO(arosen): The code in this file should be refactored
- # so it catches the correct exceptions. _validate_no_whitespace
- # raises AttributeError if data is None.
- if valid_mac is False:
- msg = _("'%s' is not a valid MAC address") % data
- LOG.debug(msg)
- return msg
+ valid_mac = False
+ # TODO(arosen): The code in this file should be refactored
+ # so it catches the correct exceptions. _validate_no_whitespace
+ # raises AttributeError if data is None.
+ if not valid_mac:
+ msg = _("'%s' is not a valid MAC address") % data
+ LOG.debug(msg)
+ return msg
def _validate_mac_address_or_none(data, valid_values=None):