On Aug 25, 2010, at 2:46 PM, Stephan Assmus wrote:
I just thought that if my observations are correct, and on the subject of advertising a certain way to write code (with regards to your initial email), perhaps new code (and eventually old code) should also follow a guideline that allows to handle allocation failures gracefully. For example, if no allocations are to be done in constructors, but rather within a dedicated init() method, objects remain always valid, even if init() throws half-way through, and they could be deallocated gracefully.
If we write code to handle allocation failures at each point where we allocate memory, one thing we’d get right away is untested code paths. Before we started adding them we’d need a really clear idea of exactly what we’d gain from this along with a testing strategy. At the moment I am not aware of specific bug reports or problems that would be best solved by adding this to the project, and it’s not clear if it would do any good to add allocation failure handling in some new code without having it in the rest of the code. It’s not straightforward to handle allocation failure in constructors without exceptions, so we might have to reverse WebKit’s current policy on using C++ exceptions or make some other major design changes. For these reasons, among others, I don’t think this is a worthwhile project for WebKit. -- Darin