BIND 10 #1542: socket creator protocol should distinguish socket level and other errors

[BIND 10 Development]

#1542: socket creator protocol should distinguish socket level and other errors
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120207
                   Priority:         |            Resolution:
  blocker                            |             Sensitive:  0
                  Component:  Boss   |           Sub-Project:  DNS
  of BIND                            |  Estimated Difficulty:  4
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
  Socket creator                     |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:7 jinmei]:
 > > I used exceptions (because it is easier to code, can contain more
 information and the code using it doesn't need to be changed (yet) to
 reflect the change). I derived a NonFatalSocketErorr (and used it as a
 base for two other exceptions, so the user of the function can have more
 details if he wants so) from the SocketError.
 >
 > I personally don't like to overuse exceptions for something we can
 > expect (and in either case it's better if we have some consistent
 > guideline of when to use exceptions in this context (i.e. not in the
 > safety vs resilience context)), but that's probably a separate general
 > discussion.  So I won't fight against it in the context of this
 > ticket.

 Well, I understand exceptions like a tool for handling unusual code flows,
 when we need to abort some operation, possibly on multiple levels of the
 stack. This is exactly the case, no matter if we can expect such an abort
 or not (in theory, we should expect an error/exception to happen
 anywhere).

 But yes, we might want to talk about it outside of the ticket, if we need
 some kind of consensus.

 > '''general'''
 >
 > I'd like to avoid hardcode numbers like "2" or "3", and ideally
 > centralize the definition of these.  one possible way is to introduce a
 > central C++ header file and share the definition for python via a
 > binding, but in this case this might be overkilling.  So defining them
 > both in C++ and in python consistently may be a compromise.

 Hmm, right. I declared them for the code, but left the magic numbers in
 for the tests, so it would be caught if the constants were set to wrong
 numbers.

 Thank you

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