What the... error handling! (try...catch)

Please check your code!

Bugs exist... and they always will.

No matter how good we are at code, or how focused is our mind while coding... there will be bugs like Coding bugs or Input bugs or whatever.

we have a duty ... to do our best to control them

A very basic way to control our code, is something really smart and easy.

Is there an error? Do this.
Not an error? Do this.
Anyway... do also this.

We can see this kind of stuff, in code like this:

const breeds = ["labrador","chow-chow","samoyed"];

try
    {
        //is there an
        akita;
        //?
    }
catch(e)
    {
        console.log("Ouch, no Akita here " + e);
        }
finally
    {
        console.log("At least there's a labrador");
    }

//-> Ouch, no Akita here ReferenceError: akita is not defined
//-> At least there's a labrador

So, what's happening here?

We created a simple:
try{}
catch{}
finally{}

try{}

Here we're trying to execute the code

const breeds = ["labrador","chow-chow","samoyed"];

try
    {
        //is there an
        akita;
        //?
    }

As you can see there's an akita variable, but nothing in the program has to do with that, so there's an error

catch{}

When an error occurs the catch{} statement is called.

catch(e)
    {
        console.log("Ouch, no Akita here " + e);
    }

All the stuff inside the statement will be executed and we will console out the String and that strange e.
That one is an Error Object a built in Object that JS provides us to capture what's happening when an error occurs.

There are lot of stuff that can be done with It. If you use e.stack It will return where in the stack the error occurred.

We can also define our custom error, later we'll see It.

finally{}

This statement, always happens.
No matter if there's an error or the code is good ... the finally{} will always be executed.

our custom error...

Sometimes, It can be really important to create our custom error.

Why?

Maybe we want give a name to that kind of error.
Maybe we want a better code, more understandable.
There are lot of good reasons.

Here It's the throw

const breeds = ["labrador","chow-chow","samoyed"];

  try
      {
          if(!breeds.includes("Akita")) 
          throw new SyntaxError("no Akita here");

      }
  catch(e)
      {
          console.log(e);
      }
//-> SyntaxError: no Akita here

See? We've just created a new "SyntaxError".
When the try meets an error the throw will immediately call the catch and a new Error will be created.

We can go deeper with this.

What If we want to create a totally new Error Object so that, the Error will be thrown only if It's an instance of that kind of Error?

We can do this:

class noDog extends Error {}

function findDog(arr) {
  if (arr.includes("Akita")) {
    return "Here you are";
  } else {
    throw new noDog("No Akita here");
  }
}

function doggy(arr) {
    try {
      return findDog(arr);
    } catch (e) {
      if (e instanceof noDog)
        throw e.message;
    }
}

console.log(doggy(["labradors","chow-chow"]));
//-> No Akita here

Hm... this is really not that easy like our previous examples.
So If you dunno what's happening here, don't be scared, It's ok.

We're defining a class that extends the built in Error.
We're just extending that class. Nothing more.
This new class has got no special properties, It's inheriting everything from the Error Object.

In short... we've created a new instance for our errors.

With that in mind, we can now catch exceptions only if those are instanceof noDog, and we can separate this kind of error, from standard one.

COOL