[bind10-dev] Exceptions - nested vs on top of header

[JINMEI Tatuya / 神明達哉]

At Mon, 27 Dec 2010 17:43:41 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> There seems to be slight disagreement during review of #447. I tend to define
> new exceptions as nested classes of whatever throws them. I have some motivation
> to do so (see below), but the rest of code doesn't seem to use that much.
[...]

> So, what the others think? Should we have a rule about which should be used? Or
> is it OK if everyone uses what feels better for him?

In my understanding there has been no agreed consensus about this type
of style issue (or more accurately we've not even discussed this).  In
that sense I think it's okay for now to use whatever the developer
wants to use.

On the other hand, I see the style inconsistency between in-class
exceptions and top level (namespace level) exceptions.  For a longer
term, it would be better to have some consensus.

I personally don't have a strong opinion about whether to have (or
prefer) in-class exceptions per se.  But I'm feeling some exceptions
are too detailed (including those I introduced) for the exception
handler.  For example, several exception classes are defined in
lib/dns/name.h but I wouldn't bother to distinguish them as separate
classes when I catch them.  The highest level of granularity would be
"some error" about names, and it should be sufficient to know more
detailed reason for the error (if necessary) via its what() message.

Based on this observation, what I'd prefer is to define (zero or) one
common exception class for each non exception class (e.g. dns::Name).
Then there should normally be no conflict among exceptions under the
same namespace (because the class names are unique).  Exception
classes in different namespaces can be distinguished by their
namespaces.  If we want to provide more detailed exception classes for
a particular (non exception) class, we'd introduce derived exception
classes from the base exception class.

Example:
namespace isc {
namespace dns {
 for class Name: exception class NameError
   NameError.what() can be "incomplete name", "empty label", "too long
   name", etc
 for class RRType: exception class RRTypeError
 for class Message: exception class MessageError
 ...
 for class Foo: exception class FooError
                   derived classes of FooError: SpecificFooError1,
                                                SpecificFooError2, ...
}
}

We might also want to have a library-level base exception class, such
as DNSException, DataSrcException, etc.  Then NameError,
RRTypeError,... will be a derived class of DNSException.

Anyway, I don't think these are blocking issue for #447, and the
ticket can move forward if and while we continue this discussion here.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.