5 ms·

> Additionally, I want to tyty to have better and more descriptive error messages than tsc's. Isn't this nice?: (https://zackoverflow.dev/tyty-errors.jpeg https

by Mawr 5y ago

> Additionally, I want to tyty to have better and more descriptive error messages than tsc's. Isn't this nice?: (https://zackoverflow.dev/tyty-errors.jpeg https://zackoverflow.dev/tyty-errors.jpeg) Actually, no. It looks fancy, sure, but error messages aren't there to be pretty, but to be usable. 1. I expect the first line of an error to give me a succinct, yet precise description of the problem. Error: Incompatible types It would never be possible for me to fix code based on this alone. Contrast with Python: TypeError: unsupported operand type(s) for +: 'int' and 'str'. I'm sure you can easily figure out what code triggered the above error just based on itself. At minimum, the first line should say which types are incompatible: Error: Incompatible types MyType and MyType2 2. How am I supposed to read the Because of this type annotation part? Is it MyFn has the type: X Because of this type annotation or Because of this type annotation MyFn has the type: X ? To fix, include guiding punctuation: MyFn has the type: X ... ... Because of this type annotation or Because of this type annotation ... ... MyFn has the type: X. Actually, it looks like it's neither and I'm somehow supposed to read it as Error: Incompatible types, because of this type annotation ... which is impossible to figure out without context. I should be able to read the error message top-down or bottom-up. To sum up, error messages are there for the programmer to be able to quickly get the gist of what happened, so they should be as obvious as possible. Check out Rust's errors for some inspiration: https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...

iddan 5y ago
I think as long as you can set the view mode with a flag to the CLI it is a great addition to the development process
maattdd 5y ago
Yes, and the fanciness part is done by another crate actually: https://github.com/zesterer/ariadne https://github.com/zesterer/ariadne.
cpcallen 5y ago
I agree that having a good summary on the first line is important, and that the actual wording of the messages shown is a little confusing, but: - The annotations shown look like a prettier version of the ones done by the Closure Compiler, which I find very helpful. - Some types can be really long, so putting two of them on the first line may not always be as readable as the TypeError example you gave. Putting them one above the other can make it much easier to spot the difference.

by Mawr 5y ago

iddan 5y ago

I think as long as you can set the view mode with a flag to the CLI it is a great addition to the development process

maattdd 5y ago

Yes, and the fanciness part is done by another crate actually: https://github.com/zesterer/ariadne https://github.com/zesterer/ariadne.

cpcallen 5y ago

I agree that having a good summary on the first line is important, and that the actual wording of the messages shown is a little confusing, but: - The annotations shown look like a prettier version of the ones done by the Closure Compiler, which I find very helpful. - Some types can be really long, so putting two of them on the first line may not always be as readable as the TypeError example you gave. Putting them one above the other can make it much easier to spot the difference.