std.experimental.allocator.make should throw on out-of-memory

Alex Parrill via Digitalmars-d digitalmars-d at puremagic.com
Tue Apr 19 15:28:27 PDT 2016


I'm proposing that std.experimental.allocator.make, as well as 
its friends, throw an exception when the allocator cannot satisfy 
a request instead of returning null.

These are my reasons for doing so:

* It eliminates the incredibly tedious, annoying, and 
easy-to-forget boilerplate after every allocation to check if the 
allocation succeeded.

* Being unable to fulfill an allocation is an exceptional case 
[1], thus exceptions are a good tool for handling it. Performance 
on the out-of-memory case isn't a big issue; 99% of programs, 
when out of memory, either exit immediately or display an "out of 
memory" message to the user and cancel the operation.

* It fails faster and safer. It's better to error out immediately 
with a descriptive "out of memory" message instead of potentially 
continuing with an invalid pointer and potentially causing an 
invalid memory access, or worse, a vulnerability, if the 
developer forgot to check (which is common for boilerplate code).

* Creating a standard out-of-memory exception will make it easier 
to catch, instead of catching each library's own custom exception 
that they will inevitably define.

Hopefully, since std.experimental.allocator is experimental, 
we'll be allowed to make such backwards-incompatible changes.

What are other peoples thoughts on this? Or has this brought up 
before and I missed the discussion?

[1] It may not be very exceptional for "building-block" 
allocators that start with small but fast allocators that may 
fail a lot, in which case returning null is appropriate. However, 
AFAIK allocators internally use the `allocate` method of the 
allocator, not make, et al., so they should be unaffected by this 
change.


More information about the Digitalmars-d mailing list