BIND 10 #1253: Datasource refactor finishing touch 3: factory/containers and wrappers

BIND 10 Development do-not-reply at isc.org
Thu Oct 6 12:10:33 UTC 2011


#1253: Datasource refactor finishing touch 3: factory/containers and wrappers
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jelte
                       Type:  task   |                Status:  reviewing
                   Priority:  minor  |             Milestone:
                  Component:  data   |  Sprint-20111011
  source                             |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:         |  Estimated Difficulty:  3
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jelte


Comment:

 Hello

 Replying to [comment:8 jelte]:
 > There is a more general issue that python does weird stuff to the symbol
 tables when it loads libraries.
 > Does the sqlite3_ds.so end up being linked to libcc? I did find another
 problem where on solaris it couldn't find the .so in the first place.

 I don't know, but it seems to work this time. Maybe it helped as well, for
 some reason.

 > So that's why i said we need to restrict by contract which exceptions
 are thrown. But given some other issues i saw, perhaps it is much better
 to restrict it even further, and not let createInstance throw anything,
 ever.

 That might make sense. But in that case, shouldn't `(...)` be caught as
 well, just as std::exception? At last in the createInstance functions?

 Thanks

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


More information about the bind10-tickets mailing list