WEBVTT 00:01.040 --> 00:07.970 Okay, so now let's test the code that we have already created by registering this error handler to 00:08.000 --> 00:11.510 handle errors and exceptions in the PHP app. 00:11.750 --> 00:19.610 And then we're going to be working on the missing parts like logging the error into an actual log file. 00:20.240 --> 00:22.760 So let's jump to the bootstrap file. 00:22.760 --> 00:29.150 This is our setup file that sets up our whole application in the command line. 00:29.150 --> 00:37.010 And when it works as a web server, one of the first things that we should do is to register the errors. 00:37.010 --> 00:45.620 So you probably remember that we have those two functions set exception handler and set error handler. 00:47.390 --> 00:56.090 So you've seen this trick before that if your callback is a method on a class, then you just pass it 00:56.090 --> 00:57.230 as an array. 00:58.220 --> 01:04.160 So we have our error handler class, which as you see gets imported here automatically. 01:04.160 --> 01:07.000 And it has this class constant. 01:07.030 --> 01:11.290 This gives the full class name including namespace. 01:14.140 --> 01:17.950 And the method here is handle exception. 01:19.690 --> 01:22.360 Now I can just copy and paste that. 01:26.590 --> 01:29.710 And this here is handle error. 01:32.470 --> 01:40.840 So I think we might even register the error handling first and only then try to load the config. 01:41.920 --> 01:45.250 Now let's try this out someplace shall we. 01:45.970 --> 01:53.080 So since currently we only have the error handling that is working in the CLI environment, we need 01:53.080 --> 01:55.990 to jump to our only CLI command. 01:56.020 --> 02:01.930 Now as you see the logic of this command is wrapped in a try catch block. 02:01.930 --> 02:09.390 And the exception handlers in PHP they catch an Catched exceptions. 02:09.540 --> 02:10.890 However, that sounds so. 02:10.890 --> 02:21.000 If you don't handle exceptions explicitly using a try catch block, then it will be handled by our global 02:21.000 --> 02:21.750 handler. 02:21.780 --> 02:28.110 Now I just want to simulate the error here because this command works. 02:28.110 --> 02:31.050 I don't expect anything to go wrong here. 02:31.050 --> 02:41.760 That's why I'll just throw an exception saying testing, exception handling. 02:42.060 --> 02:47.040 And I expect this to just show up in the command line. 02:47.520 --> 02:54.330 Now let me open the terminal and type composer schema load. 02:55.170 --> 02:57.000 So this is our error. 02:57.570 --> 03:00.060 As we expected there is a date. 03:00.090 --> 03:01.770 The color is red. 03:01.770 --> 03:05.310 And then we have a default one which is white. 03:05.310 --> 03:08.700 In my case because I'm using a black terminal. 03:08.730 --> 03:16.200 So we have all the information the class name, the actual message, and also where the error happened 03:16.200 --> 03:17.880 and on which line. 03:17.880 --> 03:26.730 So if you are running this inside VSCode, you should be able to command click in Mac or Control. 03:26.730 --> 03:34.980 Click on it on windows, which should take you directly to the file and line where the error has happened. 03:34.980 --> 03:39.510 As you see, I've just clicked that and it takes me to this file. 03:39.630 --> 03:47.550 Now also, since we have returned a non-zero code, the terminal itself is letting us know that it returned 03:47.550 --> 03:48.870 an error code. 03:50.250 --> 03:57.750 Additionally, we see a stack trace, which is super simple because in this command line script we don't 03:57.750 --> 04:01.950 even call any functions, we just throw an exception right away. 04:01.950 --> 04:11.310 The next step in our error handling is to store those errors inside a log file, so that everything 04:11.310 --> 04:15.210 that has happened can be later reviewed.