By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,442 Members | 1,437 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,442 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Nov 9 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
__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

Nov 9 '05 #2

P: n/a
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
Nov 9 '05 #3

P: n/a
* __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?
Nov 9 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.