All language subtitles for 032 Throwing unchecked exceptions_en

It's important to throw unchecked exceptions to maintain quality control.

In this lesson, you're going to learn how to throw unchecked exceptions.

First off, follow this path in your resources and open the folder, throwing exceptions, and if you're

missing this path, please download the updated resources from GitHub.

OK, before we start, we're going to place every class that models and object into a package named

models.

The reason I'm doing this is because I want to have a clear separation between classes that model an

object and the main class where we create objects.

All right, now, if you allow Vasco to refactor, it's going to import the classes for you, which

is perfect, but for learning purposes, we're going to do it ourselves.

So inside main, we get a whole lot of errors because it doesn't recognize the employee or the store

class.

That's because they're in a different folder and it can't find them.

So we need to import them.

So go to your model classes and at the very top.

We're going to write package models, this line specifies the folder that outclasses in.

You know, back in Maine, we can impart the class.

Import models, that employee.

And we can also import models that store.

Now, if you want to import every clause inside the model's folder, you can also write import models

that start.

The star basically grabs every single file inside the model's folder.

The syntax is also available in your cheat sheet.

But for the sake of simplicity, I'm just going to impart the classes separately.

OK, let's run the code.

And the store opens without any employees, the caller, the person whose programming, the main method,

they're misusing the methods and constructor's from each model.

This leads us to why do we throw unchecked exceptions, we throw unchecked exceptions that prevent the

caller from misusing methods or constructor's.

In other words, you should throw unchecked exceptions to maintain quality control.

And the most common, unchecked exceptions that you're going to throw are a legal argument exception,

an illegal state exception, they act as checkpoints to make sure the programmer fixes their code.

So inside Maine, the caller's passing is null and blank values into the employee constructor, they're

creating three employee objects with values that don't make any sense.

We're going to visualize the runtime.

And you can just tell how awkward this looks and that employees shouldn't have blank names and no positions,

every employee in the store must have a concrete name and position.

So in the constructor, we're going to check if the name or position is null or blank, if name is equal

to null.

Or if the name is blank.

Or if the position that was passed in is No.

Or if it's blank.

Then we're going to throw a new legal argument, exception.

And then as we cross the application, we're going to tell the caller the name or position cannot be

Neller blank.

This is like a checkpoint, it's going to force the caller to fix their code, we're basically telling

the caller, hey, man, if you want to use my constructor, you better pass incorrect correct values.

We're throwing an unchecked exception to inform the color of their badly written code.

Attempting to run this code.

Results in a crash.

Stepping in, stepping out.

And stepping back in.

The caller gets all the way here with the values they pastan.

But at this point, the instructor says not so fast and throws an illegal argument exception, crashing

the application.

And now the color ideally is going to recognize this failure as an unchecked exception because it happened

during the run time and they'll say, oh, OK, I got to fix my code.

In this case, we're forcing them to pass incorrect values.

So as the caller myself, I'm going to pass in the following values.

Paul, he's going to be the stalker.

Nicholas, the assistant manager.

And Damian as the manager.

All right, we're running the code.

And get.

Now, should the copy constructor throw exceptions, usually no, because the source object repass again,

it was already created with the first constructor.

So we can assume that all of its values are good.

Like, for example, let me make a copy of the stalker object.

Step into the copy constructor.

All the values are going to be good because they went through the first constructor, so we don't have

to worry about any illegal values.

But what if the user passes a null into the copy constructor, surely that's not legal.

Well, let's see what happens.

And beautiful, the copy constructor already throws a null pointer exception, which forces the caller

to fix their code so us throwing an illegal argument exception would just be redundance.

All right, let's talk about the illegal state exception, this one is thrown if an object calls a method

with an illegal status.

In other words, you need to throw an illegal state exception if an object isn't properly initialized

before calling a method.

In this case, I'll put a few break points here.

We're on the debugger.

And you can see the store object doesn't have any employees, and so we can't allow the store to open

unless it hires enough employees.

The store is not in a valid state to call the open method.

So you're going to create a for loop that runs through the length of the employees field.

And if any of the elements are No.

We're going to throw an illegal stain exception and tell the caller whoever is calling this method.

You must be fully staffed before opening the store.

Attempting to run this code or result in a crash.

The color created a store object, but didn't update the employees from the store object.

They tried to call the open method, but they're calling it with an illegal status.

So our checkpoint inside the open method crafted the application.

The color is going to recognize this failure as an unchecked exception and say, OK, I got to fix my

code in this case, we're going to call the Senate three times and update every element with an object.

And once all the positions are filled, only then are we allowed to open the store.

And beautiful.

So hope you can see that each checkpoint forces the programmer to call the methods or the constructor

properly.

In this lesson, you learn to throw unchecked exceptions.

You should throw exceptions to forbid the caller from misusing methods or constructor's.

Most common contact exceptions that you will throw are a legal argument exception, an illegal state

exception, you should throw an illegal argument exception if a constructor or method receives a legal

values.

You should throw an illegal exception if an object calls a method with an illegal status, if it calls

the method at a bad time.