So we ran into that slight little issue that popped up

when we added an uppercase value as input.

The uppercase value T is different than the lowercase value of T.

So we need to ensure a specific case in the letters of our data.

So when dealing with input, what our end user is providing us through our prompts,

like those letters, there are a few things that we can and should always do.

Firstly, we should check the correctness of the input.

This is called validation.

Input that has been checked is said to be validated.

Another option is to modify or transform the value so

that it becomes a valid value.

This process is called normalization, and the data is said to be normalized.

So in our, hey, you already guessed that letter exception example,

we validated the input and let the caller know that the validation had failed.

Now, we're looking at a place where we need to normalize the input.

We need to normalize alphabetic case of our values.

So, what we'll do is when we start the game with new Game("Treehouse"),

we'll ensure that the value is lowercase.

And then we'll also make sure that any time someone calls applyGuess on the game

object like so, we'll take whatever they gave us and make it lowercase.

A great practice to make sure things are working as you anticipate is to write what

are known as tests.

Tests exercise your code and

make sure that your code works exactly as you expected it to.

We, unfortunately, are not going to get into writing tests in this course.

But we do offer content that covers testing, check the Teacher's Notes.

So for now, while we're coding up this validation and normalization a bit,

we'll do some quick manual spot check testing.

I'd like you to get a feel for what kind of tests we might actually write, and

show you why they're such a critical part of writing applications.

Let's get to it.

Okay, so let's get to work on this bug.

I'm gonna pull this over into In Progress column.

And first off,

let's make sure that the answer that's passed in is always lowercase.

And we can do that by this, toLowerCase, right?

Remember that on strings toLowercase.

Now to tackle the guest side of things,

one thing that we haven't even checked is if our user is even giving us a letter.

So let's go explore the character class, the documentation for the character class.

So if we go here and we go Java 8, and we search for Character.

So this first result here.

So the character class is a wrapper class for our primitive data type char.

Now much like how we saw integer wrapper for a class for ints, right,

where we used integer.parseInt.

Well since a primitive char doesn't have any methods,

this class is used to provide helper methods for chars.

And it does it through, guess what., let's go look at the methods here,

through static methods.

So, here's some common getters and things.

But what we're looking for is we're looking for something that says,

is this a letter?

So, if we look through here and we say, is letter.

Hey, look at that, it takes a char and it returns a boolean of true or false.

So, let's try it out.

Let's pop over to jshell.

So, we come in here and we'll say, Character.isLetter, and

I sure hope that a is.

And boom, it returns true, cool, just like we thought.

So what happens about the character 2 or a weird @ or something?

Okay, I'll submit it works for uppercase too right?

Great, so I wonder if there's a toLowerCase for chars,

just like we looked at for the strings, I wonder if that exists.

So let's come here and I'm just going to do a search.

And a look for to, look at that, there it is, toLowerCase.

And it's a static method off of the char and

it converts the character argument to lowercase, cool.

So we could also for over here we could say a character too low and

just tap complete and boom there it is to lower case and

if we give it an a That should return as a lowercase A, beautiful.

Okay, so with that information, we should be able to get a valid lowercase letter

and throw an exception if in fact we don't.

You know what? Now is a great time to show off a concept

that we haven't touched on yet, and that is private methods.

So our game object here currently is doing some validation inside of this applyGuess.

Let's go ahead and let's make a new method and

we'll kinda group our logic together there.

So we'll make it private.

And by making this private, it will not be accessible to anyone but the class itself.

So we'll say private is gonna return a chart that has been normalized.

All right, so let's say normalizeGuess.

And it's gonna take a char and it's gonna return a char.

So again, because it's private, the prompter, like for instance, the prompter

can't say game.normalizeguess, only our code here can.

So this method is a good way to group common functionality and

not clutter up your other methods.

Here let's build it.

So first we wanna know if it is not a letter, right?

So if it is not a letter, gonna pass on letter.

Ideally this would kinda be a custom exception, but for

now we'll just do a throw new IllegalArgumentException, right?

They passed in a illegal argument to make a guess.

So we'll say a letter is required.

So now that we know it's a letter, we can transform it to lowercase.

So we can say letter =, again using that same character wrapper class,

toLowerCase(letter).

Awesome, great, now we already have some validation and applyGuess,

why don't we put that in here in the normalizeGuess.

So I'm going to cut that out, and I'm gonna paste it here.

And then finally our normalizeGuess needs to return the letter, great.

So now in applyGuess we can just call our private method there.

We'll say letter = normalizeGuess(letter).

See how it keeps things readable?

We could very easily just jam all of these lines in this applyGuess method here.

But see how nice and concise this is?

Methods provide a great way to name grouped logic.

So how about we do this, let's add a little smarts to our prompter object.

If we come over to prompter object and we look here at promptForGuess.

What if we made this thing just keep trying until it got a valid guess?

Sounds good, right?

So there's a couple ways to do this approach.

But first let's move this isHit up the top here, let's get this stuff down here.

So we move isHit to the top.

And I'm gonna bring this scanner definition to the top too.

Let's go ahead and do that.

It's kinda common to the whole method, so we'll bring him to the top.

We'll set up a new variable there.

And let's do a trick here.

Let's store a new value that we're gonna use to keep track of state in this method.

Did we get an acceptable value?

So we're gonna set that to default to start with.

Okay, so like we said, we wanna do a loop here.

We wanna loop through things, and we wanna make sure that it happens once.

So while we don't have an acceptable guess, but

we wanna make sure it happens once, so that's a do while loop.

So again, that starts like this, you say do.

And then we kinda wanna run all this stuff, don't we, to right about here.

And then we're gonna close that do loop, see how it's highlighted?

And we'll say while, we'll go not isAcceptable.

Speaking of not acceptable, look at this lineup of this code.

Let's go ahead, and I'm gonna highlight this.

And I'm gonna do a command bracket or a control bracket, right bracket.

And it will move, you can move left or right with that.

There we go.

So what we wanna do is we wanna make sure that we flip or

change the isAcceptable value to true here.

And what's happening is if it comes through here,

we know that it's valid, otherwise it's coming here.

And now, since we're looping, we can try to give a cleaner message.

So let's switch this to a printf.

And we'll put a format string here of, we'll say, here's your error message.

Please try again.

The famous Please try again.

All right, so we're gonna pump in there, just like we were before,

the exception message that we set, okay.

And we're still returning the isHit.

So this is gonna loop and will return isHit, okay.

Let's mentally walk this really quick.

So this method, promptForGuess is called.

And we set up a variable to know if it's a hit and

we set a variable to know if it's acceptable.

Our first iteration through the loop,

which will always happen because we're using a do while loop.

It's going to get an input.

It's gonna pull off that input.

And because our input returns a string, we have to use this charAt.

Sure would be nice if applyGuess took a string for us, but it doesn't.

So anyway, applyGuess takes the guess, and in here, it does some normalization.

So we pass that single charge through and it has a way of normalizing our char.

Let's take a look at that one more time.

As we come through applyGuess, it comes in here,

it calls this private method normalizeGuess.

And we pass that original guess through,

it comes through here it does all of our checks that we want.

If it makes it all the way through here, we have a valid letter.

If not, it throws an IllegalArgumentException.

Now because one of those exceptions will break out of this try block, it will run

this message, and this isAcceptable will never be flipped to true.

So therefore, when it comes back down here to check, it will go again, and

again, and again.

So let's walk that really quick with one.

So if the person entered in a 1 here, and they came and guessed, and

the guesser says, trying to be tricky for some reason, put in a 1.

They hit applyGuess, they come on over to game.

It would go to normalizeGuess, isLetter, false, a letter is required.

Here it comes, a letter is required, please try again.

And notice that it jumped over the isAcceptable.

So isAcceptable is still false.

So take a second and think about an app that you've used that takes your input.

Now this loop is pretty common right?

Whether it be on the web or on an app on your phone or tablet.

Do you follow it?

It is totally understandable for you not to grasp this immediately.

This very well may be the first time that you're thinking about

this side of the application.

But I know that you've filled out web forms before.

So you've had this experience that we're creating.

So if you need to, go ahead and pause me, and try to walk through each line there

on your own in your head, or out loud if you aren't in public.

Rewind me a bit if you wanna hear me explain it all again.

Okay so, let's give this a test run.

I am going to do a clear && javac Hangman.java && jave Hangman.

So let's make sure that we can't guess a number, right?

That was our first exception.

A letter is required, beautiful.

Nice, and there it is, it'll keep going and keep on asking me,

it's pretty insistent there.

So that works.

So what happens if I give it a capital H?

Awesome, it lowercases it.

You know what, actually we moved the code that tests the checks of duplicate

guesses into that normalizeGuess method.

So we'd better test that too, to make sure it's working.

So I'm gonna guess an h again.

Cool, it says h has already been guessed.

And then I'm gonna guess t, and then Guess it again.

Cool, and we're still at seven tries.

Nice, we did it.

Okay, great, and I just wanna point out if we had actually written a test for

all that, we'd know that we didn't break it.

Because we could just run a series of tests.

But as it stands, we have to test that every single time we change our code.

We would write tests for one, and we'd write tests for uppercase, and

we'd make sure that that worked.

In fact, we'd also test what happens if somebody just came here and pressed Enter.

No, look, it's trying to get the first

character out of a string that doesn't have any characters.

Well that code was the code we were wanting to clean up anyway.

So let's go ahead and let's close that issue.

And unfortunately, lets make a new one that says,

BUG: Sending no values on a guess causes a crash.

There we go.

And let's label that, let's give that a red label.

All right, here we go.

Nice job on the looping and exception handling.

Doing that manual testing or QA, which stands for quality assurance,

helped us to uncover another issue that we should probably fix here shortly.

If you don't enter a letter, the application encounters a critical error.

Are you beginning to see how handy it would be to be able to run

a bunch of tests and make sure everything is working at all times,

especially if you change a bit of code?

You would just run the test to make sure everything still works.

As it stands, we have to do that ourselves every single time the code changes.

All right, let's refactor in clean up that code right after this exercise.