Hi,

I was reading comp.lang.c++.moderated tonight, and read a post on exceptions,
and thought I'd ask for comments here, relating to mysql++.

Would it be useful to split up the exception hierarchy between
std::runtime_error and std::logic_error? This would introduce
multiple inheritance into the exception hierarchy if we wanted to
keep a common mysqlpp::Exception base class, but could be useful
for filtering exceptions on logic as well.

Is it worth the effort?

As I look at the exceptions, some of them would be a tough call.
For example, is mysqlpp::BadFieldName a runtime_error or logic_error
in a database GUI application where the user types in field names?

Still, thought it would be worth mentioning.

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
The only purpose for that class is to allow someone to catch all MySQL++
exceptions in a single catch block. In documenting this change, I've
also been conflating the advantages from deriving from std::exception,
which provides a consistent interface to all exceptions. So while you
don't lose out on the latter with your proposal, you do make it more
difficult to separate the MySQL++ exceptions from C++ library exceptions.

This isn't a small concern. I know you know that MySQL++ can trigger
library exceptions, such as through vector::at(). One problem I have
with these exceptions is that -- at least with current Linux standard
C++ libraries -- the what() method just returns the name of the class
that threw it. MySQL++ exceptions have much more useful what()'s, which
can be sent directly to error logs and such. Therefore, it's likely
that real programs will treat these types of exceptions differently.

Now, if you wanted to argue in favor of adding another layer just under
Exception, parallel to the division in the Standard Library, I could be
persuaded...

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Tue, Jul 05, 2005 at 05:07:07AM -0600, Warren Young wrote:
This would be a cleaner way than what I was suggesting.
I was thinking of something like:

class BadFieldName : public mysqlpp::Exception,
public std::runtime_error

But that's kinda ugly, to say the least.

I just don't know if grouping mysql++ exceptions is really that useful
in practice, so I'll leave things as is.

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:

You can avoid an inheritance diamond in that if Exception doesn't derive
from std::exception, which it does now.

True, but this offers two ways to group them: as runtime vs. logic
exceptions, and as MySQL++ exceptions vs. everything else. I've already
argued in favor of the latter. The question is whether the former is
also useful.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw