BIND 10 #1627: Error: Server configuration failed: incomplete textual name

BIND 10 Development do-not-reply at isc.org
Fri Mar 30 06:35:03 UTC 2012


#1627: Error: Server configuration failed: incomplete textual name
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:  jinmei
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20120403
  medium                             |            Resolution:
                  Component:  bind-  |             Sensitive:  0
  ctl                                |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  2
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => jinmei


Comment:

 Replying to [comment:12 jinmei]:
 > > I agree on avoiding inner try-catch blocks, but am not sure if
 maintaining a context would be less work than prepending the context and
 rethrowing, when something is thrown.
 >
 > I have a feeling that keeping a context will be useful so we can
 > produce useful exception what() (which in this context will be used as
 > a response message to the operator) in a consistent manner, even if we
 > keep the micro try-catch.  But at the moment that would probably be
 > over generalization.  So, I'm okay with leaving the block for now, but
 > I'd suggest adding some comments like:
 >
 > {{{#!c++
 >         // Note: we don't want to have such small try-catch block for
 each
 >         // specific error.  We may eventually want to introduce some
 unified
 >         // error handling framework as we have more configuration
 parameters.
 >         // See #1627 for the relevant discussion.
 >         InMemoryZoneFinder* imzf = NULL;
 > }}}
 >
 > so we can revisit the point later.

 This comment has been added.


 > > > - I think it a good idea to introduce some intermediate class
 > > >   hierarchy in for exception classes in libdns++ (in fact there
 should
 > > >   be a ticket for that, I think), but I'd like to do it based on
 some
 > > >   consistent design consideration, rather than by introducing an
 > > >   intermediate class in ad hoc manner as we see the need for it.
 > > >   e.g., isc::Exception => isc::dns::Exception => isc::dns::NameError
 > > >         => isc::dns::NameParserError => isc::dns::EmptyLabel
 > >
 > > This is perhaps good for another ticket too. I had a reason to add the
 NameParserException parent for this bug. :) We can change it however we
 want.
 >
 > I'll create a separate ticket for the redesign work.  On thinking how
 > it would probably go, I now think `NameParserError` is okay.

 Cool :)


 > Comments on the revised code:
 >
 > - I made a couple of more style fixes.
 > - one test now fails:
 > {{{
 > config_unittest.cc:335: Failure
 > Expected: parser->build(Element::fromJSON( "[{\"type\": \"memory\"," "
 \"zones\": [{\"origin\": \"example..com\"," "               \"file\":
 \"example.zone\"}]}]")) throws an exception of type EmptyLabel.
 >   Actual: it throws a different type.
 > }}}

 Oh yeah.. a different kind of exception now is thrown (as the
 NameParserException is now caught). I must have missed running make check.
 Fixed. :)

 > - also, I think we should add test cases for empty/missing zone or
 >   file name.

 Added.

 > - this could be simplified:
 > {{{#!c++
 >             imzf = new InMemoryZoneFinder(rrclass_,
 >                                           Name(origin->stringValue()));
 > }}}
 >   to:
 > {{{#!c++
 >             imzf = new InMemoryZoneFinder(rrclass_, Name(origin_txt));
 > }}}

 Done for both origin and file.

 Returning for re-review.

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


More information about the bind10-tickets mailing list