Hacker News Reader

Comment by runarberg | Hacker News Reader

In JavaScript I often find my self running the code in both firefox and chrome to get the full picture of what is undefined: (firefox)

    window.foo.bar
    //=> TypeError: window.foo is undefined

and what I'm trying to get: (chrome)

    window.foo.bar
    //=> Uncaught TypeError: Cannot read property 'bar' of undefined

Personally I find the firefox error message more useful, but often I get a better understanding of whats wrong when I run it in chrome. I don’t know why they are mentioning undefined at all and don’t say something like:

   TypeError: Cannot read property 'bar' of 'window.foo' (undefined)

---

Edit: Formatting

View on HN

The worst part is that Firefox tried to change the error message it throws to include the "bar" piece of information, and that had to be reverted because it broke sites that were parsing the exception message with regexps. :( See https://bugzilla.mozilla.org/show_bug.cgi?id=1498257 for the gory details, though it was not the only site affected: see also https://bugzilla.mozilla.org/show_bug.cgi?id=1490772 (fixed by site author) and https://bugzilla.mozilla.org/show_bug.cgi?id=1512401 (fixed by the backout).

Anyone know what the future of this is?

Sounds like they were considering trying to get sites to fix this and then redo the change, but it's not clear what happened to that in the last 5 months.

See most recent comments in the bug. The short answer is probably "there is no future here".

You're referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1498257 right?

I read all the comments, didn't get that impression, can you say why you do?

Oh, no. I'm referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1488417, which is where the change was attempted and which is marked "wontfix".

Thanks

Seems to me that a developer relying on behavior like that should be left to fend for themselves. It's not like the behavior is already consistent between implementations of ES5, or a part of its spec.

In this case "left to fend for themselves" manifests as "users end up with a non-working (on some sites) browser, switch browsers". So it's not really an option, unless the browser involved is a monopoly and the site involved has a tiny audience.

Wow. One would generally not consider exceptions part of a public API but I suppose they really are; if one rewrites it as a sort of Haskell-ish `Input -> Either Error value` one can see this directly... then if one church-encodes one also gets the way JS promises work, `Input -> forall z. (Error -> z, value -> z) -> z`...

I suppose that the "normal" response is just to say "yeah people will write bad code in any language," but maybe there was something we missed out that could have signaled to someone that this was a very bad thing they were doing? It's something that could easily happen to a junior developer. So if we had the language of our dreams, is there some other option?

Erlang's "just let it crash, do not attempt recovery but rather monitoring" comes somewhat to mind. Standardizing the error message also comes to mind, but seems a bit banal. Error codes are handy but with C I have noticed that every single piece of software has some different idea of which integers mean what things, so that developers have to absorb a hodgepodge.

Really it's I guess that you don't want any sort of conditional dispatch to happen on such a value? You would like the ability in an hypothetical programming language to mark a field as "advisory", and then the programming language checks that it never performs any sort of conditional dispatch on an advisory field. That gives you a way to make the API contract, "this contains a string but I might change that string at any later date." So if a junior dev runs into that, they are intimidated and get that sort of instant feedback they need.

> Wow. One would generally not consider exceptions part of a public API

Interestingly this happened with Java exception stack traces too. Joshua Bloch remarked that one needs to provide access to all info through standard API, if it's not there people start using toString and others and it bacames a de facto API.

Even then exceptions are likely being logged and the 'API' may be getting consumed by other processes, reporting scripts, log formatters, email rules and god knows what else. Changing an exception string can ruin a lot of peoples day.

Yes, having a way to prevent conditional dispatch on known-likely-to-change values would be good for cases like this. Adding such a language feature to JS specifically is pretty unlikely, of course. :)

Also, you may still want dispatch on "what sort of exception was this?" so then you have to provide an alternate mechanism for that...

  Every change breaks someone's workflow. [1]

  With a sufficient number of users of an API,
  it does not matter what you promise in the contract:
  all observable behaviors of your system
  will be depended on by somebody. [2]

[1] https://xkcd.com/1172/

[2] http://www.hyrumslaw.com/

Even if people rely on implementation details it can be still ok to change them. Even java, not generally known for breaking APIs, did that several times in its history.

Yes, it can, but potential breakage must be taken into account. Windows is probably the ultimate example of backward compatibility including many arguably buggy or incorrect behaviors that clients have became dependent on.

You could do this reasonably straightforwardly within an existing programming language: make a string wrapper type that had the standard I/O functionality as a "friend" or equivalent, so that printing the string to standard error prints its actual contents, but any other use turns into "The value of this string is not part of a stable API." Or more simply, provide an exception type such that getting its string description isn't a public function, but if it's uncaught from main(), whatever in the language runtime invokes main() is allowed to get the description.

That said, it sounds like the "real" problem here is that there's no programmatic way to investigate details an exception, and the answer should likely be to make an extensible structure (to which you can add new fields later) that contains the meaningful information in the exception string.... Ideally the exception string should be a static, probably translatable template string that you can use with the language's printf equivalent to fill in the per-exception data in the structured fields.

I suppose one solution would be to add a secondary error message that is mozilla specific and print that error as well when the exception is uncaught?

This is the same exact reason why PHP double colon errors still include the `T_PAAMAYIM_NEKUDOTAYIM` string somewhere in the error, as various error parsers still look for it even though the error messages have been updated to be clearer. The PHP team can't remove it or it will break tons of error parsers.

https://philsturgeon.uk/php/2013/09/09/t-paamayim-nekudotayi...

On Chrome if you click the hyperlink on the far right side of the error it brings you to the line that caused the error. Not as easy as if it were displayed as part of the error but easier than switching between browsers.

This helps but isn't always sufficient, for example in conditionals where comparing property x of two different objects.

I like the solution proposed here.

    TypeError: Cannot read property 'bar' of undefined 'window.foo'

Reply on news.ycombinator.com