Error Handling5:11 with Alena Holligan
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.
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 up