3 ms·

What programmer hasn't at some point in their career written code like this: throw new Error(`Unexpected value: ${value}. This should never happen!`); ...

What programmer hasn't at some point in their career written code like this: throw new Error(`Unexpected value: ${value}. This should never happen!`); ...and then had a user submit a bug report containing that very message. The `never` type is a nice way to model those scenarios and hopefully avoid such an error ever being seen by the user. // Compile error unless we've ruled out // `value` at the type level assertNever(value, new Error(`Unexpected value: ${value}.`));

edflsafoiewq 5y ago
The first one is a very useful error as a user though. It tells me the unexpected value isn't my fault and I should go report a bug.
- chii 5y ago
  it's not a useful message to the laymen. The message is a contradiction, which makes no sense to an untechnical person (who is also unlikely to report it properly, from experience). The will say that the computer is broken, or that the program stopped. Ideally, the user is presented with a general message telling them how to report a bug (link or something?), and include a base64 encoded blob, containing the context of the error (e.g., a stack trace, and may be also the very message in the exception), and ask the user to also submit that blob.
  - edflsafoiewq 5y ago
    Wow, I would hate that. Fortunately I've never seen it before. Seems like "the user is too dumb to lay their lowly eyes upon our error message".
    - cercatrova 5y ago
      That is correct, the average user does not know and does not care to know about the inner machinations of the software. They aren't "dumb," they just don't care. And so the onus should not be on them to file your bugs.
- _greim_ 5y ago
  Agreed that it's nice when an error message assures a user they did nothing wrong. But it's still better if the user doesn't encounter a bug in the first place due to being ruled out by the type system.
- rtpg 5y ago
  The interesting thing here is you can still get the error and display the message! Just that you _might_ be able to catch issues beforehand as well, and avoid even getting to that kind of code. Typescript's practicality here does let you walk and chew bubblegum. This sort of stuff is super practical for UI development, because ultimately at the interfaces with servers you're likely to make some assumptions about incoming data, and so you'll have that fundamental cast in your code from any to Foo, and this sort of error will be reportable.

edflsafoiewq 5y ago

The first one is a very useful error as a user though. It tells me the unexpected value isn't my fault and I should go report a bug.

chii 5y ago
it's not a useful message to the laymen. The message is a contradiction, which makes no sense to an untechnical person (who is also unlikely to report it properly, from experience). The will say that the computer is broken, or that the program stopped. Ideally, the user is presented with a general message telling them how to report a bug (link or something?), and include a base64 encoded blob, containing the context of the error (e.g., a stack trace, and may be also the very message in the exception), and ask the user to also submit that blob.
- edflsafoiewq 5y ago
  Wow, I would hate that. Fortunately I've never seen it before. Seems like "the user is too dumb to lay their lowly eyes upon our error message".
  - cercatrova 5y ago
    That is correct, the average user does not know and does not care to know about the inner machinations of the software. They aren't "dumb," they just don't care. And so the onus should not be on them to file your bugs.
_greim_ 5y ago
Agreed that it's nice when an error message assures a user they did nothing wrong. But it's still better if the user doesn't encounter a bug in the first place due to being ruled out by the type system.
rtpg 5y ago
The interesting thing here is you can still get the error and display the message! Just that you _might_ be able to catch issues beforehand as well, and avoid even getting to that kind of code. Typescript's practicality here does let you walk and chew bubblegum. This sort of stuff is super practical for UI development, because ultimately at the interfaces with servers you're likely to make some assumptions about incoming data, and so you'll have that fundamental cast in your code from any to Foo, and this sort of error will be reportable.