RFR: 8000617: It should be possible to allocate memory without the VM dying.

[Vitaly Davidovich]

An enum also provides more type safety than a bool.  If you're only ever
explicitly calling these functions with the constants, it doesn't matter;
but if you're passing the result of another function call, then it could
matter.

Sent from my phone
On Oct 15, 2012 7:54 AM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 15/10/2012 9:31 PM, Keith McGuigan wrote:
>
>>
>> On Oct 14, 2012, at 7:10 PM, David Holmes wrote:
>>
>>  On 13/10/2012 1:40 AM, Nils Loodin wrote:
>>>
>>>> So in general we have two competing wishes here:
>>>>
>>>> 1. Use std::nothrow, in operator new() and enum in the allocation
>>>> methods. (basically webrev 03)
>>>> Pros: more c++ standard-ish
>>>> cons: more boiler plate, not descriptive of what actually happens, two
>>>> different mechanisms.
>>>>
>>>>
>>>> 2. Use enums everywhere (basically a bugfree version of 04):
>>>> pros: more accurate description, cleaner implementation
>>>> cons: it's an instance of "not invented here"-syndrom, ie, we're making
>>>> up our own stuff.
>>>>
>>>
>>> I'm less supportive of using an Enum over a boolean now. A two-valued
>>> enum is a boolean.
>>>
>>
>> I disagree.  A two-valued enum adds code readability to the code, though
>> I'm sure the resulting machine code is the same.  I'd much rather see a
>> self-describing name at the callsite than a naked 'true' or 'false which
>> requires one to go refer to the function declaration (or definition) to
>> figure out what that value means.   We don't do a good job about this in
>> general in codebase -- it'd be nice to start doing it right.
>>
>
> A boolean constant can achieve the same call-site readability. If the
> parameter is "bool abort_on_oom" then you can have
>
> const bool Alloc::ABORT_ON_OOM = true;
> const bool Alloc::RETURN_NULL = false;
>
> But this is a minor and mostly stylistic issue.
>
> David
>
>  --
>> - Keith
>>
>