>>> On 22-01-07 at 18:04, in message
<[EMAIL PROTECTED]>, "Jeroen T.
Vermeulen" <[EMAIL PROTECTED]> wrote:
> On Mon, January 22, 2007 17:11, Marcel Loose wrote:
>
>> Hmm, for some weird reason I did not get this message by email, so
I
>> copied/pasted it from the web page.
>
> That may be because I'm with a state-owned Internet provider that
> regularly changes its subscribers' IP addresses *and* fails to check
for
> outgoing spam (it does censor Internet traffic, but things that are
> actually harmful are not filtered out). A few days ago I got
assigned a
> new IP address that seems to be on spam blacklists.
>
> I'm actually logging into webmail halfway across the world, but
> unfortunately the client lists the http client's address in the mail
> header so the blacklists still pick up on it.
>
>
>> Jeroen, I would think twice before walking the path of multiple
>> inheritance. This will sooner or later cause disaster, especially
>> because your exception classes keep state (i.e. have data members).
I
>> understand you're willing to adhere to the C++ standard hierarchy.
The
>> thing is that the interpretation of what represents a logic_error
and
>> what a runtime_error depends on point of view.
>
> I don't think I'm following you. What's the problem with having
data
> members in exception classes with multiple bases? The extra class
would
> be just an empty mixin--all it needs is a vtable so that RTTI can
tell the
> difference between a libpqxx-specific exception class and any other
class.
> IIRC the construct would even be eligible for the "empty base
class"
> optimization if the mixin comes first in the list of base classes.
Not
> that this is a good place to concentrate on optimization, of course.
>
> Nor do I see how the difference between a logic_error and a
runtime_error
> affects any of this. An interesting problem, certainly, but where
does it
> tie in to the question of distinguishing libpqxx-specific
exceptions?
>
>
> Jeroe
Hi Jeroen,
The problem I have with multiple inheritance is that it can cause
subtle bugs. And the place where you least want anything to go awry is
in exception classes. However, when implemented properly, there's
nothing against using multiple inheritance. I don't remember, though,
that I've ever seen a exception class hierarchy using multiple
inheritance.
The point I was trying to make w.r.t. logic_error and runtime_error is
that IMHO they are not so useful as base classes for your own exception
classes. One of the reasons is, that (ignoring the option of using
multiple inheritance) it is impossible to have one base exception class
for your own exceptions. BTW, I'm not alone in this. Bjarne Stroustrup
writes in "The C++ Programming Language, Special Edition" in section
14.10 w.r.t. the STL exception hierarchy: <quote> Some people view this
as a useful framework for all errors and exceptions; I don't. </quote>
Regards,
Marcel Loose.
_______________________________________________
Libpqxx-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
