Great news, Eric! Thanks for making the effort to test this all. Cheers!
Jay On Mon, Mar 29, 2010 at 7:25 PM, Eric Day <[email protected]> wrote: > 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 > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
