If you write some TypeScript code that is typesafe and is not using third party libraries, do you still need error handling, just because who knows what may happen?

CodePudding user response：

TypeScript helps verify the consistency of the code base itself, but your system (web app or anything else) has interfaces with the external world. When you specify these interfaces in TypeScript, it asserts that the actual interface will comply with its TypeScript description but there is no guarantee at all when the code runs.

Also, TypeScript does not verify the algorithms you are using. As a simple example it won't prevent you from dividing a number by zero. It won't verify that a recursive function has a correct exit condition either.

As a conclusion, TypeScript helps you raise some errors sooner (before even executing your code) but that does not relieve you from doing proper error handling where it's needed.

CodePudding user response：

Yes you do. Some errors are not due to unsafe code. For example, an error can occur fetching data from a server.

CodePudding user response：

Yes. Not all errors are type-related. For instance, suppose you have a function that does (say) a fetch from an endpoint. No amount of type information will change the fact that you need to handle the possibility that the request may fail. Similarly, if notifying a bunch of listeners of an event, no amount of type information will protect you from one of those listeners unexpectedly throwing an error.

I'd say that since I switched primarily to TypeScript, I haven't changed the amount of error handling I do or the level at which I do it (primarily only entry points like event handlers). I have reduced the amount of type-checking I do (I don't validate that something is a number in a function if the parameter type says it has to be a number, which I might have done in JavaScript), but not the amount of error handling.