In the last video we discussed how PHP was exception light and

used optional error messages or false E values to report a problem.

The core itself might not use exceptions much, but

they are available if you wish to use them in your own code.

And you'll certainly run into them using components or frameworks.

The problem with giving false E values is that you have to go looking for a mistake

and check the documentation to see which method provides the error message.

It's be much better to have an exception thrown at you to make it

extremely obvious.

Let's take a look at how we can throw various types of an exception from

a function and have PHP react differently to each of them.

If we look in the workspace we'll see a couple of files there which you

should recognize already from composer.

We open the index.php.

There's quite a lot of code in here, but don't panic.

I'm gonna explain what all of this means.

On line three here we have display errors which we're already familiar with.

This will help us recognize any errors that are unexpected.

We have a include vendor autoload.php which once again is, composer related.

And this is where our, our new code starts.

Basically, this is a HTTP download script which will download the body of

any URL that we provide.

On lines eight to ten here, we define multiple types of exception.

You can just use the core exception class, but

defining your own exceptions by extending the exception class makes it

much easier to distinguish different types of exception later on.

I'm breaking a few rules here by defining multiple classes and functions in the same

body, normally these should be split out into different files, but for the sake of

demonstrating, I, I kind of broke the rules there and threw them in together.

On line 13 here we're defining a function named fetch http body and

it takes one argument which is a URL.

This argument is a string value of the URL that we'd like to download.

Line 15 here instantiates a class called browser which lives

inside the buzz name space.

This is a handy little package which lets us work with HTTP interactions in

a much more sane fashion than the curl extension, and we

can rely on this working even if the curl extension is not installed on the server.

Line 16 here is using our newly instantiated browser object and

running the get method.

And passing the URL as an argument.

The response is an object.

And it's stored in this response variable.

Then on lines 18 we're downloading the content of the response.

This is the HTTP body.

The actual HTML of the response.

On line 19 here we are looking at the response object.

And running the getStatusCode method.

And storing that in a status code variable.

We'll use both these items in a moment.

On line 21 we're creating a status group variable.

And we're doing some string work on the status code to find out

what the very first digit is.

This means that if we get a code of 400 back then we only want the four.

If you're not familiar with HTTP status codes,

just know that there are lots of different codes, each with a different meaning.

And we can group these codes based on the first digit.

For example, if we get code 404 that means a missing page.

And because it starts with a four we know that it's a HTTP client error.

An HTTP client could be a web browser or in this case our PHP code.

Because the client asked for

a missing page we should tell them that they messed up.

So this status code variable can contain two, three, four, or five.

Depending on the type of exception we throw the outside code will want to

interact differently.

By using the status group variable in a switch element we can

throw different exceptions.

These rules are based on the HTTP specification, so

just go along with them if you don't completely understand the HTTP spec.

So 23, we have a switch statement looking at the status group.

And then we have a case for

each different potential value the status group can contain.

By line 25, we know the value starts with a 2,

which according to the HTTP specification, means everything worked.

That means we can go ahead and

return the content variable and there is no need for an exception.

On line 27, we know the code started with a 3 which means a redirection happened.

To let the function call know about that we can throw in new HTTP, redirect

exception with a human readable message and the specific status code included.

If we get to line 29 here.

We know that the code started with a four and

that must mean that the client made a bad request.

We can let them know about that by throwing a new HTTP client exception.

On line 31 here, we have a code starting with a 5,

which the HTTP specification explains means a server error.

So let's throw a HTTP server exception with another human readable string.

Finally, line 32 has a default case.

That means if we get an unexpected value in the status group then we

can throw a generic exception explaining that we don't know what's going on,

something weird happened.

Now, I know that's quite a lot to take in but the main takeaway here is

that different types of problem have different types of exceptions.

So reactions can differ based on the exception.

Let's take a look at some code that reacts differently based on different exceptions.

If wee look at line 39 here we'll see that we're calling our fetch HTTP body and

we're echoing the result directly.

We're also passing in a string.

This string contains a URL which will go into the URL parameter in our

function defined above.

You'll also notice that on the line above, on line 38, we have a try block.

This try means that it should look out for any exceptions being thrown, and

if the exceptions being thrown match any of these four here,

then the piece of code in that catch block will run.

We'll know which type of exception is being thrown by looking at the output of

our error, because we have this string appended on the front.

We're then outputting getMessage.

And in the case of these first three, we're also outputting the code.

If you're not sure how printf works it's just a, a, a pretty way to format strings.

Look it up in the manual if you need to understand it,

but these basically put, these values into place.

So I think it's about time that we ran our script to see what happened.

If we go to the Preview icon here.

Then we see example domain, this is exactly the output we were expecting.

We got to example.org ourselves, then that's what you see,

looks exactly the same, brilliant.

Now let's try and break it, if I put in a garbage URL like this, so

it definitely doesn't exist on the website.

Then we should be able to refresh, and perfect.

We got a client error and

the code 404 which as I explained earlier means page missing.

We go back to our code, and try and break it in another way.

We got a general error saying it failed to open stream.

Now, this isn't one of our exceptions, but it is being caught by our code.

This exception is being thrown by buzz.

They've thrown some sort of exception that we haven't made a catch for.

But because we have this catchall statement here we're catching it anyway.

This is great.

It's not only if we ensured that we're looking out for

specific events from our code and reacting to them accordingly, but we're also

using a catchall block to catch any other exceptions that we didn't expect.

Instead of simply echoing out these errors we can use them to do

useful things in our code.

A HTTP server exception might retry the connection.

A HTTP client exception might send an error to the user.

A general exception might fire off an email to somebody on the development team,

letting them know that code needs to be improved.

The point here is by reacting to specific expectations,

you can get very granular in how you react to specific problems.

Which is so much more useful than just looking for

a false return value, and then saying nope.

That didn't work.

Exceptions can take a little while to get your head around, but on a very basic

level, custom exception classes should be used like a category of exception.

Then the specific error message and code provide further information.

This is much easier than trying to work out if false is good or bad.