6 ms·

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

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
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...
Sharlin 8y ago
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/ https://xkcd.com/1172/ [2] http://www.hyrumslaw.com/ http://www.hyrumslaw.com/
- the8472 8y ago
  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.
  - Sharlin 8y ago
    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.
geofft 8y ago
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.

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

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

Sharlin 8y ago

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/ https://xkcd.com/1172/ [2] http://www.hyrumslaw.com/ http://www.hyrumslaw.com/

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

geofft 8y ago

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.