[openstack-dev] [Review] Use of exception for non-exceptional cases

Monty Taylor mordred at inaugust.com
Wed Jul 10 23:46:19 UTC 2013



On 07/10/2013 03:48 PM, Nachi Ueno wrote:
> Hi Thomas
> Thank you for your reply.
> 
>>
>> The key here is "personally". I don't think we have to agree on all style
>> issues.
> 
> "personally" is why I'm asking it for communities.
> IMO, we should agree on the style issue as much as we can. (Eg pep8, flake8)
> for more consistant review.
> However, I also agree it is hard to agree on all style issues, and sometimes
>  it is case by case.

I think the _reason_ it's important to agree on points like this where
both sides are equally correct and it's really just about personal style
is to avoid the thing Nati mentioned, which is conflicting preference
from reviewers.

The thing we decide might be "both are fine" - at which point we should
communicate it and people should not irk people about it in reviews.


>>> My instinct is the same, but EAFP does seem to be the python way. There
>>> are times I can tolerate the EAFP approach but, even then, I generally
>>> think LBYL is cleaner.
>>>
>>> I can live with something like this:
>>>
>>>   try:
>>>       return obj.foo
>>>   except AttributeError:
>>>       pass
>>>
>>> but this is obviously broken:
>>>
>>>   try:
>>>       return self.do_something(obj.foo)
>>>   except AttributeError:
>>>       pass
>>>
>>> since AttributeError will mask a typo with the do_something() call or an
>>> AttributeError raised from inside do_something()
>>>
>>> But I fail to see what's wrong with this:
>>>
>>>   if hasattr(obj, 'foo'):
>>>       return obj.foo
>>
>>
>> hasattr is a bit dangerous as it catches more exceptions than it needs too.
>> See for example
>> http://stackoverflow.com/questions/903130/hasattr-vs-try-except-block-to-deal-with-non-existent-attributes/16186050#16186050
>> for an explanation.
> 
> Thank you for sharing this.
> I'll check the obj is overwriting __getattr__ or not on the review.
> # BTW, using __getattr__ should be also minimized.
> 
> Thanks
> Nachi.
> 
>> --
>> Thomas
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list