[bind10-dev] data classes

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

JINMEI Tatuya / 神明達哉 wrote:
> At Thu, 22 Oct 2009 18:25:10 +0200,
> Jelte Jansen <jelte at isc.org> wrote:
> 
>> To get values back there are currently two versions; a set like
>> int ElementPtr->int_value(), std::string ElementPtr->string_value() etc. But
>> these are of course only relevant to one specific subtype, and for all the
>> others i can't really think of a general way to return a decent value if the
>> type is something else. So this would be a place to throw an exception (as in
>> principle you should be able to know or at least ask what type you would be
>> getting).
> 
> I have one quick question: what's wrong with throwing an exception in
> this case (except the hot fundamental point of whether to use
> exceptions in general)?  As you indicated, if someone calls
> int_value() for a non-integer element, it's clearly a bug, so throwing
> an exception seems to be reasonable to me.
> 
> Or is your main concern with this approach that you need to list all
> type-specific getter methods in the base class?
> 

well the latter is still the case if we overload it ;)

but in fact, it isn't so much the fact that the exception can be thrown, it's
more that if it can be thrown they have to be caught to make calling functions
exception-safe; for basic functions like getters this might not be ideal imho.
(the same goes for the factory functions btw)

I've been told that there are interfaces that provide both; a convenient method
that can throw exceptions and gives a guaranteed result if none is thrown, and a
faster exception-safe method, for which result values have to be checked. OTOH,
going that route makes the api biggfer again...

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrlJvMACgkQ4nZCKsdOncWOTACgonqYIpIdy732xY5VrHwUtCMS
m6oAniw1rnAeMOfCy0pSqhTW+VT7jgt0
=iHaY
-----END PGP SIGNATURE-----