From: Warren Young
Date: December 17 2007 2:41pm
Subject: Re: Exception-safety of Connection::set_option(Option*)
List-Archive: http://lists.mysql.com/plusplus/7266
Message-Id: <47668A80.60600@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jonathan Wakely wrote:
> 
> This is caused by passing an option to DBDriver::set_option_default()
> and not checking if it was already set, which means the Option object
> is leaked.

Good catch!

> The downside is that the BadOption exception thrown by
> Connection::set_option() cannot use the Option pointer, since it has
> already been deleted by DBDriver::set_option().  My patch "solves"
> this by removing the Option stored in BadOption.  You might want to do
> something else there, 

I've made BadOption hold a std::type_info reference for the option 
instead.  This then let me remove the "typeid(*o).name()" stuff from 
generated error messages: such a message is so ugly it can only be shown 
to a programmer.  The type information is better used to 
programmatically disambiguate BadOption exceptions.

> Is BadOption::what_option() essential?

It's an existing interface that I have no good reason to remove.

In v2.3, it returns a Connection::Option enum value, so the new behavior 
of returning the option object's type_info is more in line with that.  I 
just didn't think it through carefully enough when I chose to make it 
return the actual option.

> The patch also changes DBDriver::set_option to call typeid(*o) not
> typeid(o) because the  type of 'o' is just Option* so it doesn't tell
> you anything useful. typeid(*o) gives you the derived type.

Thanks for the edification.  I don't use this as in your patch, but it's 
done your way whenever I throw a BadOption now.