[onimishra]

An old but goodie. While Hejlsberg touches on a fair amount of good points in this discussion, I’ve never agreed with the end result.

He went on to make Typescript - making sure that JS has types, so when making method calls you could have the compiler tell you when you did something wrong. 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.

A lot of the described (and for myself experienced) cases against checked exceptions comes from external libraries or the language itself. IOException has a special place in hell, but for my own business logic (or inherited legacy code) in an application that spans thousands of files and classes, I would very much like to describe and be made aware of the error state throughout my application.

In Java, if I introduce a new business logic error state, all the places in my http (or cli or whatever) layer that uses that business logic will get highlighted for me, and I can then map it accordingly. In C#, that is not the case. If I don’t want checked exceptions, I can always catch it and throw a runtime exception - but I have the option. As a developer who likes to think I know what I’m doing, I would at least like the option. In C#, that decision was never mine.

With TS, we have a system that lives around being configurable. One day, I would really like to see this being up to the developer and a parameter in the tsconfig file, maybe with a configurable list of error types to be considered RuntimeExceptions. That way, if I don’t agree with a library’s use of the feature, I can tell TS to not report them by considering them Runtime.

Might just be because I use an architecture that actually favors CheckedExceptions, but not being able to describe the error states of my business logic really grinds my gears ;)

[Zababa]

> 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.