Hello again! In this video, we are going to look at error handling.
We are not talking here about bugs in your code.
These are things that can go wrong at run time, when your program interacts with the real world.
So, for example, if you try to read data from a file and the file does not exist. If you are
trying to send data over a network and the connection is down. If you receive data which is incorrect,
or in the wrong format. And so on.
So these are situations which arise at run time, when the environment does not behave in the way that
your program is expecting.
If we are just writing toy programs, we can print out a message and say goodbye, but if we want to
watch professional quality programs, we need to do a lot better than that.
When an error occurs, we need to communicate with the user.
We need to say what the problem is, and what actions the user can take.
Normally there are three possibilities.
They can try again.
They can do something to try and resolve the problem, or they can just ignore it and carry on.
We may also need to inform other concerned parties.
For example, if our company's connection to the internet is down, we may need to notify the network
management team.
We should avoid giving information which is not helpful to the user.
So things like error numbers, or Java stack traces. which may be helpful to the developer, but they are
completely unhelpful to the person stuck in front of the computer.
If the situation really is beyond help, then we can exit the program.
But that really should be your last resort.
Where should we handle errors?
The obvious answer is to handle the error where it occurs. And quite often that is going to be good enough.
For example, if you are asking for user input and they type in something which is in the wrong format,
we can ask them to try again.
But there are situations where it can be useful to handle
errors in a different part of the code where it occurs.
As an example, if we are downloading a file, so we have some networking code, at a low level,
which is doing the actual fetching of the data.
And suppose that when something goes wrong with the networking code, we want to display a dialogue box.
If we decide to handle the error where it occurs, that means that every time there could be an error,
we need to write some code to display the dialogue box.
So this means we are going to have a lot of GUI code mixed in with our networking code, which is going
to make the code more complicated.
If we are trying to follow the logic of the networking, that is going to be difficult, because there is
all this user interface code that keeps jumping up and distracting us.
And if we adopt this approach for every feature that our program has, then we are going to have error handling
spread all over the program.
There is probably going to be a lot of duplicated code. And also, it is going to be hard to work out where
the code that produces a particular dialog box comes from.
So this is going to be code which is going to be hard to maintain.
So in this situation, a better approach would be to have a specialized part of the code, which just deals with
error handling.
And then when an error occurs, we can send it off to this part of the code. And that will display the
dialogue box, or whatever we need to do.
So that means we need to be able to transfer the information about the error, from the place where the
occurs, to the code which handles it.
And we are going to be talking about how to do that in the rest of this section.
Okay, so that is it for this video.
I will see you next time.
But until then, keep coding!