List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:December 17 2007 2:41pm
Subject:Re: Exception-safety of Connection::set_option(Option*)
View as plain text  
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.
Thread
Exception-safety of Connection::set_option(Option*)Jonathan Wakely16 Dec
  • Re: Exception-safety of Connection::set_option(Option*)Warren Young17 Dec