BIND 10 #167: configure addresses and ports to listen on for DNS servers

[BIND 10 Development]

#167: configure addresses and ports to listen on for DNS servers
--------------------------+-------------------------------------------------
 Reporter:  larissas      |        Owner:  each                       
     Type:  task          |       Status:  reviewing                  
 Priority:  major         |    Milestone:  04. 2nd Incremental Release
Component:  Unclassified  |   Resolution:                             
 Keywords:                |    Sensitive:  0                          
--------------------------+-------------------------------------------------
Changes (by jinmei):

  * owner:  UnAssigned => each


Comment:

 Replying to [comment:8 each]:

 I was surprised that this is going to be a controversial discussion:-)
 I'm going to explain my points anyway, but I don't think this small topic
 is worth much time of discussion.  If you are still not convinced after
 reading this, please simply ignore my comment on this point and go ahead
 with inet_pton..

 > > Use AI_NUMERICHOST.

 > Hmm.  Thank you, that does work, but it's somewhat more accepting than I
 wanted (for example, it will happily accept an IP address of '2'), and the
 exception it throws when it sees an invalid IP address is the
 counterintuitive "Name or service not known".

 As for "more accepting", yes, I don't like that either but unfortunately
 the spec requires getaddrinfo() accept what inet_addr() would accept (BSD-
 derived implementations deliberately use stricter validation, but
 technically they are not spec conformant).

 > That would be fine if there was big performance win from avoiding the
 exception, but I don't think that's the case.  For one thing we're only
 running this code during command line argument parsing, during which
 performance doesn't matter much.  But more generally, a cascading series
 of "try...catch" statements seems to be very much the "pythonic" way of
 coding.
 >
 > (See, for example, _Python 3 for Absolute Beginners_, p. 238: "Some
 langauges try to make exception handling a last resort -- the syntax can
 often be cumbersome and the functionality basic -- and the performance of
 the language interpreter might suffer during its equivalent of 'try'
 statements.  But as you have seen, Python actively _encourages_ error
 handling, through simple syntax with a fully developed flow control based
 on exception handling.  Also, in most Python distributions, exception
 handling is no slower than simple 'if...else' flow control.")

 I'm not sure if the quoted part of text encourages cascading "try...catch"
 or it contradict my comment...when I said "his abuses an exception" I
 meant it's not "error handling" in the first place.

 But in any case, the more serious issue in this specific case is that the
 cascading style (IMO) reduces code readability, whether it's a cascading
 try-except or nested if-else.  The cascading currently reads:

 {{{
 try:
     f = socket.AF_INET
     a = socket.inet_pton(f, addr)
 except socket.error:
     try:
         f = socket.AF_INET6
         a = socket.inet_pton(f, addr)
     except socket.error as se:
         raise se
 except Exception as e:
     print(str(e))
 }}}

 Decent level programmers can probably figure out what this code does, but
 that wouldn't be immediately obvious.  And, due to the nested conditions
 it's not so easy to be confident that this code does what it's supposed to
 do from a glance.  Not at least to me - if I can claim I'm a decent level
 programmer.

 On the other hand, if you write essentially the same logic with
 getaddrinfo, it would read as follows:

 {{{
 try:
     addrinfo = socket.getaddrinfo(addr, port, socket.AF_UNSPEC)
 except socket.gaierror as err:
     raise err
 except Exception as e:
     print(e)
 }}}

 since getaddrinfo implements all the complicated nested conditions inside,
 we can concentrate on the main logic here: accept any valid IPv4/IPv6
 address.

 BTW I didn't care about performance implication at all.  I normally forget
 performance issues for something we (validly) decide to write in python.

-- 
Ticket URL: <https://bind10.isc.org/ticket/167#comment:9>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development