All language subtitles for 038 Vending Machine – Part 2 (Solution)_en

The goal apart, too, is the bullet proof, the application, a bullet proof application is free of

bugs.

It behaves exactly like we want it to and it doesn't fail or crash no matter what.

Let's run the application and put it to the test kick first.

Instead of an individual, enter a string and the application crashes, we get an input mismatch exception.

It's an unchecked exception because that happens during the runtime and as you know by now, unchecked

implies that there's something wrong, there's something missing in our code.

And what's missing in this case is code that anticipates a scenario where the user may enter a type

mismatch.

So here, before assigning a value for the row, I'm going to check if the next value scanner is going

to pick up is an integer.

If scanned, it has an int.

And if that's the case, then we'll pick up the injuries next and no problem, and if that's not the

case, I'll assign it a value of 404.

But we still need to pick up the user input, so will you scan the next line because next line can pick

up anything and this is perfect because let's just say it picks up an integer.

The next line is going to get consumed anyway by virtue of the reference trap.

On the other hand, if we return for 04, we still need to pick up the input.

We can't just leave it there.

And next line, as you know, can pick up just about anything.

All right, we'll do the same thing for Spot.

Good.

Now, let's imagine that the user messes up one of the inputs, one of these values is going to be four

of four.

So here we can say if RO.

Is equal to 404 or if the spot is equal to four 04.

Then we'll print invalid inputs.

And restart the wire loop with continue.

Let's test it out.

Eleanor, a mismatch.

And where to get and what's good about the way we designed this code is that I don't have to worry about

the reference because in the event that next event gets called, we've already got a throwaway next

line that's going to get consumed anyway.

So that's pretty cool.

OK, now I'm going to pass an invalid index.

And we get another unchecked exception array index out of bounds.

So how do we stop this crash from happening?

Somehow I need to check if the index exceeds the bounds of the array.

But once again, I'm not going to use this array for the same reason as before.

Imagine this data was being loaded from a file, which is something we're going to be doing very, very

soon.

There wouldn't even be an array in Maine.

So what I'm going to do is define a method inside the machine costs.

It's going to be called get length.

And this method is going to return the length of the array, which happens to be the number of rows.

I'll define another method, Gaturro length, that's going to return the length of Arrow.

In our case, all the rulings, lengths are uniform so we can choose any row and it's going to return

its length.

And now back here, I'm going to.

Check if the row is negative.

Or if the ROE index exceeds the length of the array, which happens to be the number of rows, don't

forget the minus one because we start indexing from zero.

We'll do the same thing for the spot and we'll check if the spot is it negative and if it exceeds the

number of spots in each row.

Again, don't forget the negative one.

If either of these comparisons ends up being true, we're going to print invalid range.

And restart the wire loop.

And that's all I'm going to test this code.

I'm just going to put random indexes that don't make any sense and perfect's.

OK, now what happens if I tried to purchase an item with a quantity of zero?

I'm going to purchase the berry twice now it's a zero if I try to purchase it again.

The application throws an illegal argument exception once again, this exception is unchecked, which

means I need to fix my code.

In this case, what's missing is code that anticipates a scenario where the user may purchase an item

with a quantity of zero.

So we'll add another else if if the machine.

Dot, and we'll get the item, get item at the requested spot, and Rowe will get its quantity and if

that quantity ends up being zero.

Then we're going to have to print empty slot.

And restart the wire loop.

Now we can try again.

I'll purchase the very.

I'll purchase it once more, and that's perfect's.

The application is now bulletproof, no matter what the user throws at you, the application is free

of bugs and it's never going to crash.

It can process any input no matter what you think about it.

And it's going to respond with grace.