Error messages
See original GitHub issueI mistakenly used xs.combine
as if it was Rx’s combineLatest
. So, I gave it a combining function.
It took me a while to debug. Not too long. A good error message would be very nice.
I’m sure that’s only one example. Thus the general title.
Issue Analytics
- State:
- Created 7 years ago
- Comments:9 (9 by maintainers)
Top Results From Across the Web
Error Messages: Examples, Best Practices & Common Mistakes
1. Write for humans (be understandable) · 2. Make sure the message is helpful · 3. Use a touch of humor · 4....
Read more >Best 10 Examples And Guidelines For Error Messages
Best 10 Examples And Guidelines For Error Messages · 1. Keep language clear and concise · 2. Keep user actions specific and logical...
Read more >How to Write Good Error Messages - UX Planet
1. Be Clear And Not Ambiguous. Write error message in clear and simple language. User should be able to understand the problem while...
Read more >Error message - Wikipedia
An error message is information displayed when an unforeseen problem occurs, usually on a computer or other device. On modern operating systems with ......
Read more >Designing Better Error Messages UX - Smashing Magazine
Error messages need to be easy to spot, but they also need to be helpful. Let's explore when error messages should live above...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I don’t want people to think I’m angry at this suggestion or not trying to help, but this suggestion won’t happen, I’m not going to build it and it’s not going to help people.
Building these type of “API misuse errors” is essentially building a weak type checking system. Please recognize that if we would try to write as perfect errors as possible, we would basically be building a crappy version of TypeScript. Worse, it’d run in runtime, not in compile time. Worse, you wouldn’t have that feedback in real time in an IDE.
I’m looking for the ideal developer experience, and the best possible error feedback of API misuse is something like a compile-time type checker or linter. And you can get awesome DX today with TypeScript.
They should if they want these helpful API misuse warning/errors. Please notice that by using JavaScript, you are acknowledging that you are taking these risks. And this happens ubiquitously with all sorts of libraries and native APIs. If you want helpful API misuse errors, the ideal solution is not to bake in those errors in runtime, the ideal solution is a typed language.
Just give it a try, TypeScript is so easy to adopt. This issue won’t happen, and it’s not because I’m ignorant to people’s problems, it’s because it would never be good enough, and the effort would be large.
I see the point, of course. How much penalty do you guys think that something like https://www.npmjs.com/package/runtime-type-checks incur?