Consistency in The Negative Result Values Through Expansion of null's Role

Erik Reppen erik.reppen at
Fri Aug 17 06:57:49 PDT 2012

Well, I was thinking !== null for most tests I guess but I could see
potential for typeof in the simpler methods that return other stuff.

So by this standard would:


be better if it returned an empty array rather than null? If that's the
case, then I guess I wanted to clear the forest for the sake of a few
missing trees.

In what cases does a null-returning method make sense from a
language-design-perspective? Or is null also a side-effect of not having
try/catch from the start?

On Thu, Aug 16, 2012 at 4:47 PM, Brendan Eich <brendan at> wrote:

> Andreas Rossberg wrote:
>> On 16 August 2012 00:35, Rick Waldron<waldron.rick at**>  wrote:
>>> On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen<erik.reppen at>
>>>  wrote:
>>>> This topic has probably been beaten to death years before I was even
>>>> aware
>>>> of es-discuss but it continues to get mentioned occasionally as a point
>>>> of
>>>> pain so I thought I'd see if I couldn't attempt to hatch a conversation
>>>> and
>>>> maybe understand the design concerns better than I likely do now.
>>>> Consistent Type Return for Pass and Fail?
>>>> The principle of consistent type-return has occasionally skewered me as
>>>> somebody who came to non-amateur levels of understanding code primarily
>>>> through JavaScript. I can see the value in maintaining consistent types
>>>> for
>>>> positive results but not so much for indicators that you didn't get
>>>> anything
>>>> useful. For instance:
>>>> * [0,1].indexOf('wombat'); //returns an index on success or  -1 to
>>>> indicate failure. -1 passed on to a lot of other array methods of
>>>> course,
>>>> indicates the last element. If you'd asked me the day I made that
>>>> mistake I
>>>> could have told you indexOf probably returns -1 on failure to find
>>>> something
>>>> but it didn't occur to me in the moment.
>>> It would be far worse to have a different type of value as a return,
>>> right?
>> Actually, no. It is far better to have something that produces failure
>> as immediately and as reliably as possible when used improperly.
>> Sentinel values are a prominent anti-pattern.
> Spoken like a true ML'er :-P. Also, you mention failure and it's true that
> lack of try/catch in original-JS and ES1&2 meant APIs had to overload
> return values with out-of-band failure codes.
> However, JS hackers do not write refutable match expressions cracking
> return value using typeof or better. *That* is the anti-pattern here.
> -1 as an out-of-band (for non-negative indexes) return code is actually
> easier to test and works well with certain code patterns, compared to a
> differently typed code. JS is not alone here, tons of precedent even in
> other dynamic languages that do have try/catch and even matching.
> The issue is "failure". Sometimes not finding the wanted character index
> is not failure but just a condition to test that leads to an alternative
> strategem. Then the conciseness and clarity of the test matters, and typeof
> rv != "number"is the wrong tool compared to rv < 0.
>  However, I agree that there is no chance of fixing that for existing
>> libraries.
> That's another thing. Deviating from existing patterns for new APIs that
> have similar names and motivations is going to be a pain for some users.
> It's not obvious to me that we have a real "failure must be prompt" problem
> here that justifies breaking with convention.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list