Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
Exceptions are different from errors. Exceptions can easily be caught and handled separately on a case-by-case basis, whereas catching errors can only be done application-wide.
-
0:00
In the last video we discussed how PHP was exception light and
-
0:04
used optional error messages or false E values to report a problem.
-
0:08
The core itself might not use exceptions much, but
-
0:10
they are available if you wish to use them in your own code.
-
0:12
And you'll certainly run into them using components or frameworks.
-
0:16
The problem with giving false E values is that you have to go looking for a mistake
-
0:20
and check the documentation to see which method provides the error message.
-
0:23
It's be much better to have an exception thrown at you to make it
-
0:26
extremely obvious.
-
0:28
Let's take a look at how we can throw various types of an exception from
-
0:31
a function and have PHP react differently to each of them.
-
0:34
If we look in the workspace we'll see a couple of files there which you
-
0:36
should recognize already from composer.
-
0:38
We open the index.php.
-
0:40
There's quite a lot of code in here, but don't panic.
-
0:42
I'm gonna explain what all of this means.
-
0:45
On line three here we have display errors which we're already familiar with.
-
0:48
This will help us recognize any errors that are unexpected.
-
0:52
We have a include vendor autoload.php which once again is, composer related.
-
0:57
And this is where our, our new code starts.
-
0:59
Basically, this is a HTTP download script which will download the body of
-
1:04
any URL that we provide.
-
1:05
On lines eight to ten here, we define multiple types of exception.
-
1:09
You can just use the core exception class, but
-
1:11
defining your own exceptions by extending the exception class makes it
-
1:14
much easier to distinguish different types of exception later on.
-
1:18
I'm breaking a few rules here by defining multiple classes and functions in the same
-
1:22
body, normally these should be split out into different files, but for the sake of
-
1:25
demonstrating, I, I kind of broke the rules there and threw them in together.
-
1:29
On line 13 here we're defining a function named fetch http body and
-
1:35
it takes one argument which is a URL.
-
1:38
This argument is a string value of the URL that we'd like to download.
-
1:43
Line 15 here instantiates a class called browser which lives
-
1:47
inside the buzz name space.
-
1:48
This is a handy little package which lets us work with HTTP interactions in
-
1:52
a much more sane fashion than the curl extension, and we
-
1:55
can rely on this working even if the curl extension is not installed on the server.
-
1:59
Line 16 here is using our newly instantiated browser object and
-
2:03
running the get method.
-
2:04
And passing the URL as an argument.
-
2:06
The response is an object.
-
2:08
And it's stored in this response variable.
-
2:11
Then on lines 18 we're downloading the content of the response.
-
2:15
This is the HTTP body.
-
2:16
The actual HTML of the response.
-
2:19
On line 19 here we are looking at the response object.
-
2:22
And running the getStatusCode method.
-
2:25
And storing that in a status code variable.
-
2:28
We'll use both these items in a moment.
-
2:30
On line 21 we're creating a status group variable.
-
2:33
And we're doing some string work on the status code to find out
-
2:37
what the very first digit is.
-
2:38
This means that if we get a code of 400 back then we only want the four.
-
2:43
If you're not familiar with HTTP status codes,
-
2:45
just know that there are lots of different codes, each with a different meaning.
-
2:48
And we can group these codes based on the first digit.
-
2:51
For example, if we get code 404 that means a missing page.
-
2:55
And because it starts with a four we know that it's a HTTP client error.
-
2:59
An HTTP client could be a web browser or in this case our PHP code.
-
3:04
Because the client asked for
-
3:05
a missing page we should tell them that they messed up.
-
3:08
So this status code variable can contain two, three, four, or five.
-
3:13
Depending on the type of exception we throw the outside code will want to
-
3:16
interact differently.
-
3:18
By using the status group variable in a switch element we can
-
3:21
throw different exceptions.
-
3:23
These rules are based on the HTTP specification, so
-
3:25
just go along with them if you don't completely understand the HTTP spec.
-
3:29
So 23, we have a switch statement looking at the status group.
-
3:32
And then we have a case for
-
3:33
each different potential value the status group can contain.
-
3:37
By line 25, we know the value starts with a 2,
-
3:39
which according to the HTTP specification, means everything worked.
-
3:43
That means we can go ahead and
-
3:45
return the content variable and there is no need for an exception.
-
3:48
On line 27, we know the code started with a 3 which means a redirection happened.
-
3:53
To let the function call know about that we can throw in new HTTP, redirect
-
3:57
exception with a human readable message and the specific status code included.
-
4:01
If we get to line 29 here.
-
4:04
We know that the code started with a four and
-
4:05
that must mean that the client made a bad request.
-
4:08
We can let them know about that by throwing a new HTTP client exception.
-
4:12
On line 31 here, we have a code starting with a 5,
-
4:15
which the HTTP specification explains means a server error.
-
4:19
So let's throw a HTTP server exception with another human readable string.
-
4:23
Finally, line 32 has a default case.
-
4:26
That means if we get an unexpected value in the status group then we
-
4:28
can throw a generic exception explaining that we don't know what's going on,
-
4:31
something weird happened.
-
4:33
Now, I know that's quite a lot to take in but the main takeaway here is
-
4:36
that different types of problem have different types of exceptions.
-
4:39
So reactions can differ based on the exception.
-
4:42
Let's take a look at some code that reacts differently based on different exceptions.
-
4:46
If wee look at line 39 here we'll see that we're calling our fetch HTTP body and
-
4:51
we're echoing the result directly.
-
4:54
We're also passing in a string.
-
4:55
This string contains a URL which will go into the URL parameter in our
-
4:59
function defined above.
-
5:01
You'll also notice that on the line above, on line 38, we have a try block.
-
5:04
This try means that it should look out for any exceptions being thrown, and
-
5:08
if the exceptions being thrown match any of these four here,
-
5:12
then the piece of code in that catch block will run.
-
5:15
We'll know which type of exception is being thrown by looking at the output of
-
5:18
our error, because we have this string appended on the front.
-
5:23
We're then outputting getMessage.
-
5:26
And in the case of these first three, we're also outputting the code.
-
5:29
If you're not sure how printf works it's just a, a, a pretty way to format strings.
-
5:34
Look it up in the manual if you need to understand it,
-
5:36
but these basically put, these values into place.
-
5:40
So I think it's about time that we ran our script to see what happened.
-
5:42
If we go to the Preview icon here.
-
5:45
Then we see example domain, this is exactly the output we were expecting.
-
5:51
We got to example.org ourselves, then that's what you see,
-
5:54
looks exactly the same, brilliant.
-
5:56
Now let's try and break it, if I put in a garbage URL like this, so
-
6:00
it definitely doesn't exist on the website.
-
6:02
Then we should be able to refresh, and perfect.
-
6:05
We got a client error and
-
6:06
the code 404 which as I explained earlier means page missing.
-
6:09
We go back to our code, and try and break it in another way.
-
6:13
We got a general error saying it failed to open stream.
-
6:16
Now, this isn't one of our exceptions, but it is being caught by our code.
-
6:20
This exception is being thrown by buzz.
-
6:23
They've thrown some sort of exception that we haven't made a catch for.
-
6:27
But because we have this catchall statement here we're catching it anyway.
-
6:31
This is great.
-
6:32
It's not only if we ensured that we're looking out for
-
6:33
specific events from our code and reacting to them accordingly, but we're also
-
6:37
using a catchall block to catch any other exceptions that we didn't expect.
-
6:40
Instead of simply echoing out these errors we can use them to do
-
6:43
useful things in our code.
-
6:45
A HTTP server exception might retry the connection.
-
6:48
A HTTP client exception might send an error to the user.
-
6:52
A general exception might fire off an email to somebody on the development team,
-
6:55
letting them know that code needs to be improved.
-
6:58
The point here is by reacting to specific expectations,
-
7:01
you can get very granular in how you react to specific problems.
-
7:04
Which is so much more useful than just looking for
-
7:06
a false return value, and then saying nope.
-
7:09
That didn't work.
-
7:10
Exceptions can take a little while to get your head around, but on a very basic
-
7:13
level, custom exception classes should be used like a category of exception.
-
7:18
Then the specific error message and code provide further information.
-
7:22
This is much easier than trying to work out if false is good or bad.
You need to sign up for Treehouse in order to download course files.
Sign up