BIND 10 #1025: logging argument should be more carefully checked

[BIND 10 Development]

#1025: logging argument should be more carefully checked
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:         |             Milestone:
  defect                             |  Sprint-20110712
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  Unclassified                       |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  0.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by stephen):

 > As for the additional check in boost::lexical_cast, we should at least
 catch boost exceptions within it and convert it. I'm not so sure if
 obscuring it is a good idea in that IMO it's not a good idea if we simply
 e.g. return from a function when it sees a parameter that should not have
 a particular value in that context (e.g. a NULL pointer).
 My thought was that if we encounter an unusual situation and we can
 continue, we should. Ideally we should log the problem, but here the error
 is in the logging code itself and I was trying to avoid any unforeseen
 problems of having the code log a message in the middle of logging a
 message. (There might be none at the moment, but allowing it may constrain
 us in the future. And in any case, if we do log a message, we are still
 left with the question of what to return to the calling function.)

 As to the more general case of encountering a problem,  I think we should
 try to log the condition but continue if possible. Of course, this depends
 on the problem.  So if a configuration value is read that is above an
 allowed maximum (say), I think it would be permissible to log the error
 but continue as if the maximum had been specified.

 Things get more awkward if the error occurs in a more critical area of the
 code.  For example, if an error is detected in the data source structure
 whilst servicing a query, what should we do?  Obviously log the error and
 quite probably abandon the query: but should we stop the server?  On the
 one hand, such an error might imply that the data source can't be trusted.
 On the other hand, the corruption might be localised and the bulk of
 queries could continue.  I don't think there is an absolute right answer,
 but perhaps we should try to develop some guidelines.

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