Okay, welcome back.

Earlier when we implemented the event functionality,

we wrote incomplete error handling code.

So if we go all the way up to the purchase method,

you'll see that there's just an empty catch block.

We're throwing errors when they occur, but we're not doing anything to handle them.

Let's fix that now by showing our users an alert if something goes wrong.

An alert view is represented by the class, UIAlertController.

And it has a simple init method that takes

all the information we need to construct and display an alert.

Since we have three different alerts that we're going to display depending on

the error the user has run into, let's create a single method that can create and

display different alert views for us.

I'm going to add this at the end of the vend section here.

So after the updateQuantity method.

And we'll call this method showAlert.

Creating an alert view is really simple.

Again we're going to use the UIAlertController class, and

it has a initializer method that we can easily use to pass some arguments.

So I'll say let alertController.

Now we're gonna create an instance of UIAlertController and

we use this initializer method that takes a title, message, and a style.

For the first one, we'll say the title is Out of Stock.

The message which will be displayed under the title will say,

This item is unavailable.

Please make another selection.

And for the style we're going to say alert because we're displaying an alert.

Now this preferred style here, this parameter is of type UIAlertController

style, which again is an enum with members to represent the different alert styles.

So that's it.

Now we have an alertController.

How do we show it though?

To get one view to show another view,

we actually designate that task to the viewController,

because again, a viewController controls that view hierarchy.

So we're going to ask this viewController to show another view,

which is also in turn controlled by a separate controller.

And we're going to shoot on top of the current view.

And we do that using a method, present.

Present takes a viewController to present.

So we'll pass in the alertController, and we do want to animate this, so

we'll say, true.

And then for the completion handler which is some code that is executed

after we've presented the view.

For now we'll just say no because we don't want it to do anything.

Presenting and showing views is not a simple task, but a lot of the heavier

lifting is done for us by UIkit and the methods implemented in UIViewController.

Again note that I'm saying present the alertController, not the alert view,

because the alertController then goes ahead and

controls that segment of views, its own view hierarchy.

This style of presenting a viewController from a containing

viewController is used to implement a modal interface.

A modal view is a child view that is displayed on

top of the main view to perform a different set of actions.

Modal views prevent the user from interacting with the underlying view

until they perform the action required by the modal view.

You should be familiar with this.

When an alert pops up on your phone, you can't simply go back to using the regular

app until you either acknowledge or dismiss that alert.

This is intentional.

You display a modal of you when you want the user to take it related but

separate set of actions, that then determines what happens in the main view.

Modal views can be full screen as we will see shortly, or

they can take up just a bit of the screen like an alert, which is also a modal view.

Either way, they prevent input on the underlying view.

So yeah ,as we mentioned, by default if you ask a viewController to

present another viewController, it displays that set of views modally.

An app has a view hierarchy, and ours currently looks like this.

Presenting a modal view makes that view appear directly on top of the view stack

like this.

This seems intuitive but it's important to understand how the view stack

changes as we present and dismiss views.

As we learn about other modes of navigation,

you'll see that the stack behaves differently.

Okay, now that we can show one alert, let's modify our error handling code.

Now this specific alertController that we created informs the user that we're out

of stock.

So we'll use this if we hit the out-of-stock error.

So go all the way back up to the purchase method.

And right here in the do catch block, we'll catch on the VendingMachineErrors,

outOfStock case, and then in here we will simply say show alert.

Now you'll get an error once we've change the code here, and that's because now by

catching on a specific error, our do catch clause isn't exhaustive.

We're not handling any other error cases, for

example what happens if we hit the vending machine errors, insufficient funds, or

invalid stock, or invalid selection I mean, or any other set of errors.

For that we're going to add an empty generic catch block, for

now we'll fix this.

But this way it sort of makes our error handling exhaustive, right?

So if we catch on this specific error,

we're going to execute the code inside this clause which is showAlert,

any other error and we'll go here, which for now does nothing.

Again this isn't good practice but we're going to fix this.

So now let's run the app again.

So let's try that again, let's select an item, and a max on the quantity.

And now if we hit Purchase, you'll see that we get an Out of Stock error.

Look at that.

So we have an alert here.

The look and presentation style of the alert is controlled by the system, so

we're just using the defaults here.

Since this view's presented modally, we can't interact with the underlying views.

But we don't have a way to dismiss this either.

So let's stop the app, and figure out how to do that in the next video.