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