is there any reason not to inherit from std::exception

[__PPS__]

Hi, I've read in documentation to different libraries that their
exception classes aren't subclasses from std::exception, and a separate
catch statement is required for their exceptions. Always, I don't
understand why they do so and want to fix this feature (most of the
time, I go to edit source), even in their docs they write like this:
try {
// Close the database
db.close(0);
// DbException is not subclassed from std::exception, so
// need to catch both of these.
} catch(DbException &e) {
// Error handling code goes here
} catch(std::exception &e) {
// Error handling code goes here
}

and it's obvious that even their comment is repeated. Well, if their
DbException was derived from std::exception but provided extra
functionality we still can use it, and at the same time it's possible
to catch(const std::exception&) to, at least, get some desription of
error

(this piece of code comes from db4 c++ docs)

so, why is that so common that libs provide their hierarchy of
exception classes similar to std::sceptions ??
thanks

[Jonathan Mcdougall]

__PPS__ wrote:

Hi, I've read in documentation to different libraries that their
exception classes aren't subclasses from std::exception, and a separate
catch statement is required for their exceptions. Always, I don't
understand why they do so
Ask them.
and want to fix this feature (most of the
time, I go to edit source), even in their docs they write like this:
try {
// Close the database
db.close(0);
// DbException is not subclassed from std::exception, so
// need to catch both of these.
} catch(DbException &e) {
// Error handling code goes here
} catch(std::exception &e) {
// Error handling code goes here
}

and it's obvious that even their comment is repeated.
That's an example of bad comment use.
Well, if their
DbException was derived from std::exception but provided extra
functionality we still can use it, and at the same time it's possible
to catch(const std::exception&) to, at least, get some desription of
error

(this piece of code comes from db4 c++ docs)

so, why is that so common that libs provide their hierarchy of
exception classes similar to std::sceptions ??

Well, some people like to derive from std::exception, some don't. Those
who do usually say something like "you can catch any exception using
std::exception only" and those who don't usually say "my exceptions
aren't standard so they shouldn't be derived from std::exception".

It's a matter of taste.
Jonathan

[Bob Hairgrove]

On 8 Nov 2005 23:42:08 -0800, "__PPS__" <i-*********@yandex.ru> wrote:

Hi, I've read in documentation to different libraries that their
exception classes aren't subclasses from std::exception, and a separate
catch statement is required for their exceptions. Always, I don't
understand why they do so and want to fix this feature (most of the
time, I go to edit source), even in their docs they write like this:
try {
// Close the database
db.close(0);
// DbException is not subclassed from std::exception, so
// need to catch both of these.
} catch(DbException &e) {
// Error handling code goes here
} catch(std::exception &e) {
// Error handling code goes here
}

and it's obvious that even their comment is repeated. Well, if their
DbException was derived from std::exception but provided extra
functionality we still can use it, and at the same time it's possible
to catch(const std::exception&) to, at least, get some desription of
error

(this piece of code comes from db4 c++ docs)

so, why is that so common that libs provide their hierarchy of
exception classes similar to std::sceptions ??
thanks

The message function, std::exception::what(), always returns a const
char *, so if you want to use Unicode text, it means jumping through
hoops to internationalize the error message (although it *is* possible
to use std::string and const char * when UTF-8 is the chosen encoding
type).

Otherwise, it's possible that some libraries have wrapper classes
around database exceptions, OS exceptions, etc. which might not always
play well with other exception types.

--
Bob Hairgrove
No**********@Home.com

[Alf P. Steinbach]

* __PPS__:

so, why is that so common that libs provide their hierarchy of
exception classes similar to std::sceptions ??

I don't know that it's common, but where it's done it's usually obvious
that it's due to incompetence.

Some times, however, an exception that _isn't_ caught by
catch(std::exception const&) is needed, one that will propagate all the
way up through many layers of exception-catching software.

Unicode really isn't an issue, both because Unicode can be represented
as UTF-8, because exceptions should not carry user interface messages,
and because it's trivial to add a direct Unicode representation where
needed.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?