Take a look at this try-catch demo:

```typescript
const tryCatchDemo = (state: "fail" | "succeed") => {
  try {
    if (state === "fail") {
      throw new Error("Failure!");
    }
  } catch (e) {
    return e.message;
  }
};
```

TypeScript is giving us an error on `e.message` that the object is of type `unknown`.

## Challenge

Your challenge is to coerce the `unknown` type into one where we know what it is.

Hint: there are a few ways to solve this challenge-- see what you can come up with!

When using a try-catch in TypeScript, it’s important that you type the error appropriately. There are a few different techniques to accomplish this.

As mentioned, there are several ways to solve this problem.

## Use Any Type

One way to solve this challenge is to type `e` in the `catch` as `any`:

```typescript
} catch (e: any) {
  return e.message;
}
```

We can use `any` because we're pretty confident that the error is going to be an error.

What makes this solution not ideal is that we lose autocomplete on the `e`. This makes it easy to end up with typos that can cause issues later.

This isn't the solution I would suggest.

## Coerce as Error

A slightly better solution would be to coerce `e` to be an `Error`, and return the message:

```typescript
} catch (e) {
  return (e as Error).message;
}
```

Here `e` is still `unknown` when we enter the `catch`, but using `as` coerces it to an `Error` and we get our autocomplete as expected.

This solution is about as unsafe as the one above - we're not _checking _if `e` is an Error, we're casting it as an error.

## Check with instanceof

This solution is pretty similar to the last, except this time we'll use `instanceof` to see if `e` is an `Error`:

```typescript
} catch (e) {
  if (e instanceof Error) {
    return e.message;
  }
}
```

Unlike previous solutions, this time we're checking `e` at runtime to whittle down what it could be.

We're not blanketing it with the `any` type and we're not casting it to something else either.

This is my recommended solution, because it's the safest.

If you get something that isn't an error, it will fall down to the next block where you could do something else with it.

However, depending on the constraints of your codebase and how much you care about avoiding `any`s, you may prefer one of the other solutions.

Techniques for Coercing an Unknown Type

0:00 This one has several solutions. Here, we're just doing it as an any. We can use any in this position because we're pretty confident that the error is going to be an error. It's not the ideal solution because this e here, we lose all autocomplete on it and it's very, very easy to do something like this and not notice it, and have a typo here and we don't even realize it, which would make the test fail.

0:28 Any, it's fine if you want to use it and it's very, very low impact here. It's just going to be within this block. If you really want to do it right, then I wouldn't suggest doing any.

0:40 The next way to do it is pretty similar, I would say, is you've got e as error inside here. E is unknown here. Then you coerce it to say, "e is an error," and then you extract the message from it. Here, we're not saying it's any here. We do get things from it. We get message, we get name, we get stack. If I add a typo here, then it's going to alert me. This is a little bit better.

1:06 Technically, if this block was longer and more complicated, which yours in production are usually going to be, then e might not be an error. You might end up with someone accidentally saying, "Throw failure," in which case, you're going to return undefined here. This is not the perfect solution either, but it's better than the previous one.

1:28 This one is a better solution. What we're doing here is we're saying e is unknown in this position, but we're checking e and checking if it's an instance of error here. This is like the typo that we saw earlier. That instance of is then going to whittle down what that error can be. We've got e.message, e.name, e.stack.

1:52 Unlike the previous ones, we are actually checking at runtime what that type is and doing something based off that. We're not casting it using the as that we saw before, and we're not blanketing over it with any, which we also had before.

2:07 This is my recommended solution. It's also pretty tight. If you get something that isn't an error, then it's going to fall down into this block, and you might need to do something else with it. This is probably the safest approach. Depending on the constraints of your code base, your time constraints, and how much you care about avoiding anys, then you might want to prefer one of the other solutions.

Typing Errors in a Try-Catch

0:00 The problem with this exercise is that we're testing a tryCatch. I've mocked up this situation where we can make the tryCatch fail when we want to. If we have state === "fail" here, then we throw the error.

0:14 We're getting this error here because object is of type 'unknown'. That's because anything that you catch inside an error here, inside a catch block, is going to be unknown.

0:25 We need to somehow coerce this unknown to be the type that we want it to be, that we know it is. It's going to be an error here. We somehow need to extract the message from that error.

Get hands-on interactive practice with this free TypeScript tutorial and learn the foundational knowledge and skills you need to become a TypeScript Wizard.

In this TypeScript tutorial you will:

* Learn to type variables, functions, and errors
* Become familiar with the TypeScript documentation
* Gain experience with modern TypeScript tooling

[Start now](https://totaltypescript.com/tutorials/beginners-typescript/implicit-any-type-error), and see why TypeScript’s an essential tool for modern web developers!

<Testimonial author={{name: "David Stinemetze", image: "https://cdn.sanity.io/images/z9io1e0u/production/6b24aef92c60f25c88fd8da44e97a1a47cb64e7b-150x150.png"}}>The Beginner’s course is fantastic. Very well explained, and easy to navigate through. I went through it in preparation for the <a href="https://totaltypescript.com/workshops" target="_blank" rel="noopener">extra paid workshops</a>, just to ensure I had a solid foundation and even then I learned some new things. Thanks Matt!</Testimonial>

## Instructions

This Beginner’s TypeScript tutorial is split into several exercises. Each features a `problem` that encourages you to take an active, exploratory learning approach to finding a `solution`.

To attempt a solution, you’ll need to:

1. Watch and read the `problem` introduction.
2. Check out [the TypeScript docs](https://www.typescriptlang.org/docs/).
3. Search for relevant keywords.
4. Give it a go to see if it solves the problem (there may be more than one solution!)

Whether you succeed or get stuck, watch & read the `solution` and check out the included code.

### Prerequisites

You’ll need a working understanding of JavaScript.

### Running the Exercises Locally

Clone [the Beginner’s TypeScript Tutorial repo](https://github.com/total-typescript/beginners-typescript-tutorial), and use npm or yarn to install dependencies.

If you [follow this link to use gitpod](https://gitpod.io/#https://github.com/total-typescript/beginners-typescript-tutorial), you can work in a full VS Code coding environment running in your browser.

Follow the [instructions in the README](https://github.com/total-typescript/beginners-typescript-tutorial) for more.

Free interactive video tutorial that will help you get started with TypeScript.

Beginner's TypeScript Tutorial Repo

First thing’s first: dealing with the implicit ‘any’ type error.

Fix the Implicit 'Any' Error

The Implicit ‘Any’ Type Error

Not all of the functions you write will take primitive types. When you need to pass objects as parameters, there are a few different ways to type them properly.

Add Types to Object Params

Working with Object Params

TypeScript can’t tell by itself if your code will still work when object properties are missing. For these situations, you need to specify which are optional.

Denote an Optional Property

Set Properties as Optional

Just as we saw with object properties, function parameters can be set as optional as well.

Mark a Function Parameter as Optional

Optional Parameters

Assigning types to variables allows TypeScript to provide more useful error messages on the lines where they occur.

Make a Variable Conform to an Interface

Assigning Types to Variables

TypeScript allows us to constrain a property’s value to one of a set number of things. For example, a medal that could only be gold, silver, or bronze.

Delineate Types a Value Can Be

Constraining Value Types

Arrays are one of the most common data structures in development. In this lesson, find out how they are represented in TypeScript.

Two Ways to Represent Arrays

Working with Arrays

Being strict about what is returned from your functions ensures that your code is safe on the inside as well as the outside.

Annotate a Function to Specify its Return Type

Function Return Type Annotations

Almost every web application involves making API calls. But how can we tell TypeScript what to expect when we’re expecting data?

Update Return Type Annotations for Async Functions

Typing Promises and Async Requests

One of the most crucial TypeScript concepts to understand is how type arguments work with certain functions and constructors.

Pass a Type Argument to Restrict Potential Types

Passing Type Arguments

Seeing “index” in a type error message usually refers to the key of an object. In this lesson are a few techniques for properly typing dynamic object keys.

Techniques for Typing Dynamic Object Keys

Assigning Dynamic Keys to an Object

TypeScript offers powerful features for narrowing down branches when working with third party APIs or functions that support data in different forms.

Change Function Returns Based on Type

Narrowing Down Union Types

Interfaces can inherit properties from other interfaces. This allows us to DRY out our code and have a neater way to work with complex data models.

Extend Interfaces From Other Interfaces

Inheriting Interface Properties

TypeScript allows for composing types together to create new types. This is useful when returning data that is a combination of multiple different types.

Combine Inline or at the Type Level

Combining Types to Create New Types

TypeScript provides us with tools for being more selective when creating new types based on others.

Two Techniques for Creating New Types Based on Others

Selectively Construct Types from Other Types

TypeScript supports typing functions that are passed in as arguments, including the arguments that they take.

Specify the Type of a Function

Typing Functions

TypeScript supports typing the returns from asynchronous functions– great for real world processes like fetching from databases or other third-party APIs.

Transcript

Typing Errors in a Try-Catch

Transcript