WEBVTT 00:00.120 --> 00:06.870 Hello again! In this video, we are going to compare exceptions in C++ with exceptions in Java and C#. 00:10.960 --> 00:16.360 The first difference is, there are not as many situations in which C++ throws exceptions. 00:16.780 --> 00:22.960 If you have a run-time error which could cause a crash or data corruption, such as accessing through a null 00:22.960 --> 00:29.470 pointer, or a null reference, or dividing by severe, you will get an exception in Java or C#, 00:29.840 --> 00:31.660 but you will not get one in C++. 00:32.590 --> 00:38.710 In C++, the program will continue to execute, and its behaviour will be undefined. Which probably means 00:38.710 --> 00:42.040 it will crash, or cause data corruption, or do something weird. 00:43.120 --> 00:49.010 And the reason for that is that there are differences in design philosophy. In Java and C#, 00:49.490 --> 00:56.410 program safety is regarded as very important. And in C++, efficiency is regarded as very important. 00:58.920 --> 01:04.020 C++ has a design principle which says, "you should not have to pay for anything you do not eat." 01:04.830 --> 01:11.430 So this means, if you are dividing by something which you know is not zero, then having the program check 01:11.430 --> 01:14.280 for it and raise an exception is just a waste of time. 01:16.270 --> 01:21.550 In the Java and C#, all exceptions are inherited from a system exception class. 01:22.600 --> 01:28.000 So if you want to write a handler which can catch any type of exception, you just need to catch an 01:28.000 --> 01:34.540 instance of the system exception. In C++ any type could be used for an exception, including 01:34.540 --> 01:40.090 built-in types, although the recommended practice is to inherit from something in the standard library exception 01:40.090 --> 01:40.750 hierarchy. 01:41.980 --> 01:47.470 If you do need to catch for every possible type of exception, then you need to use a special syntax 01:47.800 --> 01:49.690 for the "catch-all" handler. 01:52.730 --> 01:54.880 In Java, there are two types of exception. 01:55.280 --> 01:58.760 So-called "checked" and "unchecked" or run-time exceptions. 01:59.870 --> 02:06.140 If there is a checked exception, you have to handle it immediately where it occurs. If you do not do 02:06.140 --> 02:07.760 that, then your code will not compile. 02:09.940 --> 02:13.660 For the unchecked exceptions, then you're not required to handle it immediately. 02:13.960 --> 02:17.680 You can let it propagate up the call stack for someone else to handle. 02:19.500 --> 02:23.700 In C++ and C#, there is nothing resembling a checked exception. 02:26.220 --> 02:33.590 So, in Java terminology, all exceptions in C++ and C# are unchecked: you are not required to handle 02:33.920 --> 02:35.700 them and then, unless you want to. 02:40.280 --> 02:46.610 In Java, if an exception is not caught, the default behavior is to print out a stack trace and 02:46.820 --> 02:49.370 terminate the thread in which the exception occurred. 02:50.180 --> 02:54.770 And you can override that. In C++, if there is an uncaught exception, 02:55.130 --> 02:57.980 then the program is terminated, although again, you can override this. 02:59.100 --> 03:01.830 In C#, I could not find a clear answer on this. 03:02.580 --> 03:08.520 It seems that sometimes you run inside a framework, and the framework will pick up unhandled exceptions. 03:09.120 --> 03:13.230 But if you do have an exception which propagates all the way to the main() function, then your program 03:13.230 --> 03:14.190 is terminated. 03:15.120 --> 03:18.900 By the way, I am not claiming to be an expert on Java or C#! 03:19.470 --> 03:21.840 It has been several years since I last looked at them. 03:22.620 --> 03:28.090 If I do say something which is incorrect or out of date, then I apologize and maybe someone can tell 03:28.090 --> 03:29.940 me what the current situation is. 03:31.270 --> 03:36.700 Java and C# have a garbage collector, and this has implications for exceptions. 03:38.630 --> 03:44.900 If you have a class which has some operating system resource, such as an open file, for example, 03:45.500 --> 03:48.230 that object must release the resource. 03:48.500 --> 03:55.200 It must close the file before the garbage collector disposes of the object. And it can happen 03:55.250 --> 03:58.790 that the garbage collector destroys the object before it has released 03:58.910 --> 04:04.040 the resource. So these languages provides another block, called "finally". 04:05.180 --> 04:11.180 And in this "finally" block, you can put code which will release the resource. So that prevents 04:11.180 --> 04:12.620 the resource leakage from happening. 04:15.420 --> 04:20.700 In more recent versions of Java, there is something called "try with resources", so you can declare 04:21.150 --> 04:23.040 a resource object in the try header. 04:24.390 --> 04:29.100 And if there is an exception, then the close() method will be called for that object. 04:30.470 --> 04:34.280 And you can do something similar in C# with the "using" keyword. 04:38.440 --> 04:45.730 In C++, we can avoid all this by using the RAII idiom. So the resource is wrapped inside the class, and the 04:45.730 --> 04:48.940 destructor of this class will release this resource. 04:49.900 --> 04:53.690 The key here is that the destructor is always called deterministically. 04:53.710 --> 04:59.800 So as soon as the object is no longer in use, then the object is destroyed. And with RAII, that will 04:59.800 --> 05:01.630 also release the resource as well. 05:02.170 --> 05:07.240 So this is all deterministic and synchronous. So there is never any possible window in which you have 05:07.240 --> 05:10.450 an unreleased resource for an object that has been destroyed. 05:11.710 --> 05:16.270 The other advantage is that we only have to write the code that does this once, in the class's destructor, 05:16.750 --> 05:20.560 as opposed to having to write it every time we use an object of that class. 05:21.760 --> 05:23.230 OK, so that is it for this video. 05:23.650 --> 05:26.640 I will see you next time, but until then, keep coding!