Interpreting Errors
Since TypeScript is a heavily focused Developer Help oriented programming language, its errors messages try to be super helpful when something goes wrong. This can lead to a slight information overload for unsuspecting users of compilers that aren't so helpful.
Lets look at an example in an IDE to break apart the process of reading an error message.
This example demonstrates a common programmer error where they fail to call a function (bar: getBar
should be bar: getBar()
). Fortunately this mistake is caught by TypeScript as soon as it doesn't meet the type requirements.
Error Categories
There are two categories of TypeScript Error messages (succint and detailed).
Succint
The objective of the succint error message is to provide an example conventional compiler description of the error number and message. For this example the succint message looks like:
It is fairly self explanatory. However, it doesn't provide a deeper breakdown of why the error is happening. That is what the detiled error message is for.
Detailed
For this example the detailed version looks like:
The objective of the detailed error message is to guide the user to the reason why some error (type incompatability in this case) is happening. The first line is same as the succint, followed by a chain. You should read this chain as a series of responses to the developer question WHY?
between lines i.e
So the root cause is,
for property
bar
there is a function
() => string
while it was expected as astring
.
This should help the developer fix the bug for the bar
property (they forgot to invoke ()
the function).
How it shows up in an IDE Tooltip
The IDE normally shows the detailed
followed by the succint
version in a tooltip as shown below:
You normally just read the
detailed
version forming theWHY?
chain in your head.You use the succint version if you want to search for similar errors (using the
TSXXXX
error code or portions of the error message)
Last updated