Could someone clarify what Andrew is saying here?

What Andrew is meaning is that some errors (such as the one regarding the "bad" url protocol) are fetched by the Node API immediately , which then throws an exception that contains the stack trace.

To avoid this immediate "crash" of our program, we need to make use of the try/catch blocks. This lets us not only print out a readable error messages, but also prevents our programm from crashing when an exception occurs.

Try/catch blocks are used extensively in other programming languages to handle exceptions. Even though javascript provides us a nice and clear way of handling errors(by listening for error events using .on), there are still some edge cases that require us to handle exceptions with a try/catch.

The main takeaway is, that a try/catch block lets you write code that won't stop execution as long as the exception is handled!

I believe he was trying to vaguely introduce the idea of different error complexity and handling. An error in your application's logic is catastrophic and shouldn't be allowed into production (but we all know it does happen as we've had programs crash unexpectedly).

However there are also errors that aren't a problem with how the application runs or it's logic but rather something else gets messed up along the way. The most common of these is a failure to get the resources we were expecting. This type of error is outside the hands of the developer at production time so it needs to be anticipated so the program can "fail gracefully" and let the user know why it happened (and what steps should be taken).

An example would be a request for pictures from the Flickr API. Say you have a photo blog and want to display photos dynamically from Flickr on your personal blog. So you have a request get the pictures from Flickr and then your website formats and displays them on the page. But what if Flickr changes their API? Or maybe they are doing server updates when you send the request for your pictures so the Flickr server responds with an error message instead of the requested pictures.

In this instance it would be good for your application to catch the error and tell the user of your site that there was a problem with Flickr and to try reloading the site again in a minute. This is more informative and useful to your users than the program just crashing to a blank page.

Anyway, that's a long way of saying there are some errors you expect and design for, and some you don't expect and cause a catastrophic failure of your application. You think about and handle these types of errors differently.

The protocol of a URL is typically "http://".

So it sounds like a "bad" URL is one which is missing this part at the beginning. That would mean the sample you show above would be a "bad" one.