Hi everyone, Over the weekend Monty mentioned some boost docs around throwing exceptions around modules, and this led me to experimenting with exceptions again to see if I could make them work a bit differently. After some testing, I found that you actually can pass them around reliably as long as you are careful about the symbol visibility settings with your shared objects. It is also suggested to use virtual inheritance when deriving from std::exception.
This worked on latest Ubuntu, SunCC/sparc, and gcc 4.1 on oldest supported CentOS. So, this is no longer a reason to not use exceptions. There are still other runtime costs to consider and general code maintainability, but the portability issues should not be a concern. -Eric On Mon, Mar 22, 2010 at 11:39:00AM -0700, Eric Day wrote: > Hi everyone, > > We've been using the STL quite liberally with much of the new Drizzle > code, but we've been doing little to no exception handling around > it. Right now most calls to std::string/STL methods that could > modify/allocate underlying data structures could fail, and without > a catch, this is the equivalent to putting an assert() after every > malloc call ensuring it succeeded. While this may make Stewart happy > since we are essentially taking the crash-only software approach, > I worry we're not catching edge cases and cleaning up properly. Also, > not all failures should lead to the server halting. > > This extends beyond simple memory allocation as well, for example > std::out_of_range can be thrown if passing invalid indexes into some > STL container methods as well. > > Beyond handling exceptions throw by string/STL, there have also > be discussions about Drizzle's use of exceptions in general. For > portability reasons, you can't reliably throw custom C++ exceptions > across shared object boundaries because RTTI (run time type > information) will not always be correct. We either need to decide > to not allow exceptions to cross shared library boundaries (thinking > plugins mainly) or not worry about supporting the platforms/compilers > that can't handle it (which first requires identifying them). > > My suggestion would be to: > > * Not allow custom exceptions. There may be a possible exception for > some plugins which require them if they are based on other libraries > that use them, but this should be discouraged. > > * Never allow exceptions to propagate across module boundaries. > > * Catch string/STL exceptions as close as possible to the source and > translate those into return codes. This allows calling methods to > do the correct thing, whether it be abort a query, abort a session, > or halt the entire server. > > What do other folks think? > > -Eric _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
