8 ms·

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 bro

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 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1490772 (fixed by site author) and https://bugzilla.mozilla.org/show_bug.cgi?id=1512401 https://bugzilla.mozilla.org/show_bug.cgi?id=1512401 (fixed by the backout).

gpm 8y ago
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.
- bzbarsky 8y ago
  See most recent comments in the bug. The short answer is probably "there is no future here".
  - gpm 8y ago
    You're referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1498257 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?
    - bzbarsky 8y ago
      Oh, no. I'm referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1488417 https://bugzilla.mozilla.org/show_bug.cgi?id=1488417, which is where the change was attempted and which is marked "wontfix".
      - gpm 8y ago
        Thanks
artursapek 8y ago
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.
- bzbarsky 8y ago
  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.
crdrost 8y ago
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.
- Boulth 8y ago
  > 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.
  - flukus 8y ago
    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.
- bzbarsky 8y ago
aidenn0 8y ago
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?
ermir 8y ago
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-nekudotayim-v-sanity/ https://philsturgeon.uk/php/2013/09/09/t-paamayim-nekudotayi...

gpm 8y ago

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.

bzbarsky 8y ago
See most recent comments in the bug. The short answer is probably "there is no future here".
- gpm 8y ago
  You're referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1498257 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?
  - bzbarsky 8y ago
    Oh, no. I'm referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1488417 https://bugzilla.mozilla.org/show_bug.cgi?id=1488417, which is where the change was attempted and which is marked "wontfix".
    - gpm 8y ago
      Thanks

artursapek 8y ago

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.

bzbarsky 8y ago
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.

crdrost 8y ago

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.

Boulth 8y ago
> 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.
- flukus 8y ago
  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.
bzbarsky 8y ago

aidenn0 8y ago

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?

ermir 8y ago

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-nekudotayim-v-sanity/ https://philsturgeon.uk/php/2013/09/09/t-paamayim-nekudotayi...