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

Brendan Eich brendan at
Fri Aug 17 07:18:55 PDT 2012

Erik Reppen wrote:
> 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:
> 'squirrel'.match(/wombat/);
> be better if it returned an empty array rather than null?

Probably not. Again, the main consideration is usability. If you want to 
catch mismatch -- and regexp matchers do, often -- then with an empty 
array on mismatch, you'd have to write

   var m = r. match(s);
   if (m.length == 0) { /* mismatch handling here */ }

or trickier equivalents, but not

   if (!m) { /* mismatch handling here */ }

While empty array does convert to empty string, the match array in 
general is not used as a concatenation part. Any captured groups would 
add extra elements to the array, and a /g flag would make all the 
matches pop out. The "blind concatenation" use-case isn't there, in my 

Experience is what drivers good API design, namely user experience and 
usability. Most match users want to know about mismatch and handle it. 
Whether mismatch is "failure" or "fallback", it's a fork in the 
program's control flow, most of the time.

This is much less so the case with charAt.

> If that's the case, then I guess I wanted to clear the forest for the 
> sake of a few missing trees.

Systematizing a-priori based on a theory of failure or a one-true OOB 
return value is probably a mistake. Sometimes -1 works, other times "", 
yet others null or even a thrown exception. The design depends on the 
particulars. Channel Aristotle, not Plato.

> 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?

Null has its uses. If you think of undefined as "no value" and null as 
"no object" and use undefined for any-value-returning methods, and null 
for maybe-object returning methods, you won't go too wrong.

> On Thu, Aug 16, 2012 at 4:47 PM, Brendan Eich <brendan at 
> <mailto:brendan at>> wrote:
>     Andreas Rossberg wrote:
>         On 16 August 2012 00:35, Rick Waldron<waldron.rick at
>         <mailto:waldron.rick at>>  wrote:
>             On Wed, Aug 15, 2012 at 6:02 PM, Erik
>             Reppen<erik.reppen at
>             <mailto: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
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list