Hello again! In this video, we are going to compare exceptions in C++ with exceptions in Java and C#.
The first difference is, there are not as many situations in which C++ throws exceptions.
If you have a run-time error which could cause a crash or data corruption, such as accessing through a null
pointer, or a null reference, or dividing by severe, you will get an exception in Java or C#,
but you will not get one in C++.
In C++, the program will continue to execute, and its behaviour will be undefined. Which probably means
it will crash, or cause data corruption, or do something weird.
And the reason for that is that there are differences in design philosophy. In Java and C#,
program safety is regarded as very important. And in C++, efficiency is regarded as very important.
C++ has a design principle which says, "you should not have to pay for anything you do not eat."
So this means, if you are dividing by something which you know is not zero, then having the program check
for it and raise an exception is just a waste of time.
In the Java and C#, all exceptions are inherited from a system exception class.
So if you want to write a handler which can catch any type of exception, you just need to catch an
instance of the system exception. In C++ any type could be used for an exception, including
built-in types, although the recommended practice is to inherit from something in the standard library exception
hierarchy.
If you do need to catch for every possible type of exception, then you need to use a special syntax
for the "catch-all" handler.
In Java, there are two types of exception.
So-called "checked" and "unchecked" or run-time exceptions.
If there is a checked exception, you have to handle it immediately where it occurs. If you do not do
that, then your code will not compile.
For the unchecked exceptions, then you're not required to handle it immediately.
You can let it propagate up the call stack for someone else to handle.
In C++ and C#, there is nothing resembling a checked exception.
So, in Java terminology, all exceptions in C++ and C# are unchecked: you are not required to handle
them and then, unless you want to.
In Java, if an exception is not caught, the default behavior is to print out a stack trace and
terminate the thread in which the exception occurred.
And you can override that. In C++, if there is an uncaught exception,
then the program is terminated, although again, you can override this.
In C#, I could not find a clear answer on this.
It seems that sometimes you run inside a framework, and the framework will pick up unhandled exceptions.
But if you do have an exception which propagates all the way to the main() function, then your program
is terminated.
By the way, I am not claiming to be an expert on Java or C#!
It has been several years since I last looked at them.
If I do say something which is incorrect or out of date, then I apologize and maybe someone can tell
me what the current situation is.
Java and C# have a garbage collector, and this has implications for exceptions.
If you have a class which has some operating system resource, such as an open file, for example,
that object must release the resource.
It must close the file before the garbage collector disposes of the object. And it can happen
that the garbage collector destroys the object before it has released
the resource. So these languages provides another block, called "finally".
And in this "finally" block, you can put code which will release the resource. So that prevents
the resource leakage from happening.
In more recent versions of Java, there is something called "try with resources", so you can declare
a resource object in the try header.
And if there is an exception, then the close() method will be called for that object.
And you can do something similar in C# with the "using" keyword.
In C++, we can avoid all this by using the RAII idiom. So the resource is wrapped inside the class, and the
destructor of this class will release this resource.
The key here is that the destructor is always called deterministically.
So as soon as the object is no longer in use, then the object is destroyed. And with RAII, that will
also release the resource as well.
So this is all deterministic and synchronous. So there is never any possible window in which you have
an unreleased resource for an object that has been destroyed.
The other advantage is that we only have to write the code that does this once, in the class's destructor,
as opposed to having to write it every time we use an object of that class.
OK, so that is it for this video.
I will see you next time, but until then, keep coding!