This workshop will be retired on May 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Handling fatal errors in the past has been next to impossible in PHP. A fatal error would not invoke the error handler and would simply stop your script. On a production server, this usually means showing a blank white screen, which confuses the user and causes your credibility to drop. It can also cause issues with resources that were never closed properly and are still in use or even locked. In PHP 7, an exception will be thrown when a fatal and recoverable error occurs, rather than just stopping the script.
Documentation
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Next, we're going to cover
the changes to error handling.
0:00
Handling fatal errors in the past
has been next to impossible in PHP.
0:04
A fatal error would not invoke the error
handler and would simply stop your script.
0:08
On a production server, this usually
means showing a blank white screen.
0:14
Which confuses the user and
causes your credibility to drop.
0:18
It can also cause issues with
resources that have never closed, and
0:23
are still in use, or even locked.
0:27
In PHP 7, an exception will
be thrown when a fatal and
0:30
recoverable error occurs,
rather than just stopping the script.
0:34
Fatal errors still exist for certain
conditions, such as running out of memory,
0:38
and still behave as before by
immediately stopping the script.
0:44
An uncaught exception will also
continue to be a fatal error in PHP 7.
0:48
This means that if an exemption was thrown
from an error that was fatal in PHP 5 and
0:54
it goes uncaught,
it will be a fatal error in PHP 7.
0:59
I wanna point out that other types
of errors such as warnings and
1:02
notices remain unchanged in PHP 7.
1:08
Only and fatal and
recoverable errors throw exceptions.
1:11
In PHP 7, error and exception both
implement the new Throwable class.
1:15
What that means is that they basically
work the same way and also, you can now
1:21
use Throwable in a try catch block to
catch both exceptions and error objects.
1:26
Remember that it is better practice to
catch more specific exception classes and
1:33
handle each accordingly.
1:38
However some situations warrant
catching any exception such as for
1:40
logging or framework air handling.
1:45
In PHP 7 these catch all blocks should
catch Throwable instead of exception.
1:48
Here´s what the new hierarchy
looks like in PHP 7.
1:54
The Throwable interface is implemented,
by both exception and error.
1:57
Under error,
we now have some more specific errors.
2:03
Type error, parse error, a couple
arithmetic errors and assertion error.
2:06
If Throwable was designed in PHP 7 code,
it would look like this.
2:13
If you've worked with exceptions at all,
this interface should look familiar.
2:17
Throwable's specialized methods nearly
identical to those of exception.
2:21
The only difference is that Throwable
2:26
hit previous can return any instance of
Throwable instead of just an exception.
2:29
Here's what a simple
catch-all block looks like.
2:34
Try any code that may throw
an Exception or Error, catch,
2:37
Throwable, and handle exception in PHP 7.
2:43
To catch any Exception in PHP 5 and
7, with the same code,
2:46
you would need to add a catch block for
Exception.
2:50
After catching Throwable first.
2:53
Once support for
2:56
PHP 5 is no longer needed, the block
catching exception can be removed.
2:57
Virtually, all errors in
PHP 5 that were fatal,
3:02
now throw instances of error in PHP 7.
3:05
Without catchable errors,
our code would look something like this.
3:09
And it returns a fatal error and
stops our script.
3:14
Without errors displayed to the screen,
we would just see a blank white page.
3:17
Like any other exception, error objects
can be caught using a try catch block.
3:21
And some errors will throw a more
specific subclass of error.
3:26
Let's take a look at some examples.
3:29
A TypeError instance is thrown
when a function argument or
3:32
return value does not
match a type declaration.
3:36
In this function, we've specified that
the argument should be an int, but
3:40
we're passing in strings that
can't even been converted to ints.
3:44
So the code is going to throw a TypeError.
3:48
This could be used for adding shipping and
handling to a shopping cart.
3:51
If we passed a string with the shipping
carrier name instead of the shipping cost
3:54
our final total would be wrong.
3:59
And we would risk losing
money on the sale.
4:01
A ParseError is thrown when
an included required file or
4:05
evaluated code contains a syntax error.
4:09
In the first try we'll get a parse
error because we called the undefined
4:12
function var_dup instead of the var_dump.
4:17
In the second try,
4:21
we'll get a parse error because
the required file has a syntax error.
4:22
Let's say we check if a user is logged in,
and if so, we want to include a file that
4:27
contains a set of navigation links,
or a special offer.
4:32
If there is an issue with that
include file, catching the parse error
4:36
will allow us to notify someone
that the file needs to be fixed.
4:40
Without catching the parse error,
4:44
the user may not even know that
they're missing something.
4:46
These changes to error handling
are mostly backwards compatible, but
4:49
if you've created your own error class.
4:53
After upgrading PHP you'll
get a PHP fatal error,
4:55
cannot declare class error because
the name is already in use.
4:59
You'll have to rename your error
class since the PHP7 class name error
5:03
is predefined and used internally.
5:08
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up