fix memory leak from constructor exceptions

[peterhillman]

Addresses #256 and #258, based on fix suggested in #256
Signed-off-by: Peter Hillman peterh@wetafx.co.nz

[meshula]

This looks to be a lot more robust. The repetition of the clean up block is worrying - the worry is that in the future if someone touches code near one of the clean up blocks, and also makes a change in that nearby clean up block, they might not consistently apply a necessary fix in all the repetitive instances. Would it make sense to have a private clean up method, that also assigns nullptr to _data after the delete, in order that we are future-proofed against this possibility?

[peterhillman]

@meshula, how about this approach? Nesting the try/catch blocks rather than having the same cleanup code in two alternate catch blocks? It seems a little ... unorthodox ... and we still have two similar code blocks in the two separate constructors. They aren't quite identical though, and I'm not sure if those differences are necessary.

[meshula]

This version is easier to follow. The double nesting of try's feels a bit... pythonic, in the sense that some of our existing APIs are a little "leap before you look". I think the nesting as you have it is fine given the way the rest of the code works. A future pass could involve adding API to check if the resize within initialize() is possible, before actually going through the actual work, but I think it's more important to correct the leak before contemplating deeper changes.