Try & catch finally JavaScript & Typescript
By: Arnold Abraham
Tags: Programming, JavaScript, Software Development, Typescript, Web Development

Try/Catch In TypeScript

Escape any error exception in Typescript 4.0 with unknown

Did they do it on purpose?

TypeScript covers many concepts from JavaScript. Also, the questionable ones. Some cases of error handling can be quite interesting, but this article will guide you through the jungle!

Microsoft describes TypeScript as a superset for JavaScript. What do I mean by telling you this? Simply every TypeScript code is also a valid JavaScript one. TypeScript can do more than its parent, but not less. If it wouldn’t the migration of projects wouldn’t be as easy as it is and the acceptance by the developers would also be shrinking.

Because of that, they also took the bad ones. Like the exception handling. If you break it down, the error handling is pretty similar to the one in C#. Throw is used to trigger an exception. And as you guess this one right, you will also guess the next: try & catch are used to handle them. Therefore, it is irrelevant if the exception is a default or a user-defined one.

Finally also made it into TypeScript. You can only use try-finally, no need for a catch here. Finally is used to make sure we clear unneeded memory allocations. But this is nothing new, this is implemented for years now.

It has not even to be the error type?!

Although JavaScript does not have a classical type system, it provides several error types. Error — This is the globalized error type used for any occasion. SyntaxError — is specified as thrown when a syntax error occurred and the ReferenceError — when any value is assigned to an undeclared variable or assignment without the var keyword or a variable is not in our current scope [1].

The language differentiates those three types and throws one of them when the circumstances are right. Or in our case, then the code has an error. Typescript derived all these errors, and that means the following code is simply valid.

There is one question floating around in my head. What type does the parameter exception have?

I think it is obvious this has to be the type Error or at least one type that has a common ground with all other named error classes. Some kind of Error — Interface.

The type of the parameter is any. This makes us do whatever we want because the compiler won’t complain, whatever we do with our parameter exception. We will get access to any defined properties. Typescript does not apply the otherwise strictly used type safety.

Two questions here:

Why is that so? Why could this be meaningful?

I answer the first question in a manner of seconds: JavaScript does not force us to use the error as an exception. You do not even have to derive from it, you can throw anything you want, a ball, a nut, a baseball bat… It lies in your hands.

This throw is pointless but syntactical correct. For the execution of this code, the program will catch us the value 42. The answer to everything in the universe.

And that’s the answer to the first question. Typescript infers from any because it can not guess or even know what code in other parts of our program could throw.

What comes next is the answer to the question, if this is even good?

Error error error

I actually don’t think that this is good. Why? Because instead of supporting an unsafe error type, Typescript should put a stop to it!

But how could you do that? The backward compatibility is the main promise Typescript gave us developers. It could simply use another type than any. For example unknown. It wouldn’t be much of a difference, because of unknown limits the accessibility to properties by even giving no opportunity to do so. And that’s for a reason, we don’t know what the unknown is, so it is therefore just logical not to access a thing, we don’t even know.

Unfortunately, this brings not more type safety but a bit of general safety, because of the fact not letting us accessing properties. And since Typescript 4.0 it is possible to declare a type inside the catch statement. We are forcing the program to explicitly declare any or unknown. We want the unknown type to reach our goal.

Since linters are a blessing for every developer and teams also, there is also a rule for that. ESLINT-plugin [2] got the rule of no-implicit-any-catch [3]. This will help you force anybody to code try &catches that are helpful. You can even force to use the type unknown. This is very helpful in the manner of type safety. And that’s why you use Typescript.

Type-Guard

Because you will already have a lot of any-typed exceptions on your code, you don’t want to change them all manually, but to work well with exceptions you better convert them. A Type-Guard is a useful way to do so. This one has to check if a value has the right type and, if possible, converts that value.

And of course, there is an NPM-Module for that. And hell yes, why not? The name is defekt [4]. This one can make your own error classes. For example, this one.

Conclusion

I love Typescript & JavaScript as well. They are great languages to turn out simple ideas pretty quick and accessible for everyone. They are also great to make really cool and extraordinary web applications. But one thing that Typescript has to get rid of are things like the topic covered by this article. Simply taking old error-prone properties of JavaScript and letting them untouched. On the other hand, what would TS be without the backward compatibility to JS? I really can’t make an accusation against Microsoft to do so. TS wouldn’t be so big if there were no backward compatibility.

And for that, it is even more important to know your language and to understand what’s happening under the hood and where your language comes from. JavaScript is the basement of modern web.

Further reading:

Links & References

[1] Exception Handling

https://basarat.gitbook.io/typescript/type-system/exceptions

[2] eslint-plugin

https://eslint.org/docs/developer-guide/working-with-plugins

[3] no implicit any catch

https://tinyurl.com/y8vckrmx

[4] NPM modul Defekt

https://www.npmjs.com/package/defekt