7 ms·
Unless you are actually handling out of memory errors and running in production with memory overcommit turned off, you probably should just panic if malloc fail
by hedora 2y ago
Unless you are actually handling out of memory errors and running in production with memory overcommit turned off, you probably should just panic if malloc fails. Disabling exceptions achieves this in C++.
If you are trying to handle OOM, then you should at least have a big fuzz test setup that causes malloc to spuriously return null, and also set your debug builds to do this too.
Good luck writing stable software that way (vs just not dynamically allocating stuff on the heap) —- everything becomes exponentially more complicated and difficult to reason about / test.
- amluto 2y agoHuh? This has nothing to do with memory failure. Imagine: class UTF8String { public: static optional<UTF8String> FromBytes(const void *buffer, size_t len); private: UTF8String(...); void *bytes; size_t length; }; UTF8String::FromBytes can fail if the input is invalid. In this particular case, it can obviously be implemented without constructing a UTF8String until it's past the point of no return. But I can imagine cases where pulling this off is awkward.