4 ms·
> "proper" error handling via return values would mean everything that allocates memory has to have an error return path and everything that calls anything that
by PittleyDunkin 2y ago
> "proper" error handling via return values would mean everything that allocates memory has to have an error return path and everything that calls anything that has that somewhere in the chain needs to still propagate that error.
That seems like a win to me for the aforementioned "readable" criteria—failures should be enumerated. But I can see how that would be annoying to write.
I'm also of the opinion that if handling out of memory is a serious consideration for your process, you should consider using your own allocator that doesn't fire an exception. This is how rust handles it, for instance. And on top of this I'm a little confused because exceptions are mostly disallowed from embedded codebases, which is the primary place where you would likely run out of memory and want to actually handle it.
- ryandrake 2y agoDisallowing exceptions is a company policy, though, not something imposed by the language. I'm not going to go into whether I think it's a good or bad policy, but just pointing out that you can write embedded software that properly handles exceptions. Granted, the discipline, will (and yes, budget) to do this is pretty rare in embedded shops.
- PittleyDunkin 2y agoWell, that's rather beside the point—if you're really worried about allocators failing, exceptions don't provide any benefit over simply returning NULL.
- kllrnohj 2y ago> exceptions don't provide any benefit over simply returning NULL. Sure they do - they don't negatively impact the non-error case and don't pollute every function's return value.