> Again, errors/exceptions did not get a throw clause, making it impossible to model the error state that the language provides. You can describe, in detail, the data for successful run, but are unable to describe the data for any error state. If the goal was to make the system more sound, I have a hard time seeing why the error state is not taken into account.
I think the idea is that exceptions are too hard to handle without going too far from JS, so you're supposed to handle errors Go-style, but instead of [result, error] you can return result | error thanks to union types. TS is here to statically type JS, but it can't check for exceptions, so pushing people to use them would greatly reduce the value of the tool.
I've said this in another comment, but I really think sum/union types can give you 90% of the benefits of checked exceptions. In the article, `FileNotFoundException` is mentionned. That's something that could be handle with the function returning File | FileNotFound. You can achieve this with sealed classes in C# and Java, but it sounds painful to do this every time. Like someone else said, with checked exceptions you have ad-hoc unions, instead of having to create them yourself with sealed class. Since you have neither sum types, nor unions in Java or C#, checked exceptions in Java are your best tool to handle your case.