Suppose you had the index of pets open in your browser and

you clicked the link to open the show page for one of them in a new tab.

You do some random browsing and

then go back to the first tab and click the delete link for that pet.

Some more random browsing.

And then you go back to the show page tab and click Reload.

You'll get this error, ActiveRecord::RecordNotFound.

What should you do in this case?

Possibly nothing.

The record is missing because it's supposed to be.

You deleted it, after all.

In the rare event that something similar happens in production,

rather than a RecordNotFound error,

your users will see a 404 page indicating they tried to access a nonexistent page.

If you want finer control over these errors,

though, one thing you can do is to rescue the exception.

We can go into app/controllers/pets_controller.rb,

find the show action, and edit it to add a rescue clause to rescue the exception.

So we can say rescue ActiveRecord::RecordNotFound,

since that's the exception we were getting.

In the event that we get such an error, we can put up a flash

message of type notice, saying we couldn't find that pet.

And then we can redirect users back to the index of all pets.

Save that, and let's try reloading the page with the missing pet.

Reload it and we get redirected back to the index of all pets with a flash

message, we couldn't find that pet.

You'll have to decide which is right for your app,

explicitly handling load errors or just letting it show a 404 page.

The ability to explicitly handle errors is there if you want it, though.

Sometimes, RecordNotFound errors can be more serious, though.

Suppose we were getting this error every time we clicked an Edit link for a pet.

ActiveRecord::RecordNotFound Couldn't find pet with ID, and nothing.

And if we look in the stack trace, we see this is occurring at

app/controllers/pets_controller.rb line 26 in the edit method.

Let's try opening the file mentioned in the stack trace and see what we find.

We'll open app/controllers/pets_controller.rb and

we'll go to line 26.

The problem seems to be with that call to Pet.find but

maybe you can't see what it is just yet.

Let's take another look at the error.

It says, couldn't find pet with ID, blank.

It seems like there should be an ID number after 'id'=.

That's a little strange.

Let's take a look at exactly what we're passing to Pet.find.

Rails apps have a logger object which writes text messages to your terminal

and to a file.

All those messages you've seen regarding GET and POST requests, errors,

and so on were displayed by the logger.

And you can display your own messages using the logger too.

You can call the logger method within the code for any Rails controller,

model, or mailer.

That'll return a logger object,

and there are several methods that you can call on that object.

All these methods take a string and add it to the log.

The difference is how important that message is.

Debug messages aren't very important and

should only be included in the log when debug mode is turned on.

Info messages have information about what the app is doing.

They're probably safe to omit from the log in most cases.

Warn messages indicate a potential problem.

They should probably be included in the log.

Error messages are definitely a problem and

should be included in the log no matter what.

And fatal messages indicate a problem so

serious that the app is probably about to shut down.

Okay, so we need to use a log message to look at the contents of params[:pet].

Since Rails apps turn debug messages off by default, even in development mode,

we're going to call the info method to add a message to the log.

So we'll add some code right before the line where the error occurs.

We'll call logger to get the logger object.

I'll call the info method on it and I'll pass a string to it.

The :pet parameter is, and

I'll interpolate some Ruby code into the string,

#{params}, close the interpretation,

close the string out, and end the method call.

Let's save that.

And now let's refresh our browser page so

that it runs the pets controller edit method again.

That will run the code that calls logger.info.

Once that's done, scroll back through your log and you'll see your message.

The pet parameter is nothing?

That can't be right.

We need to figure out what's going on.

If you look at the log right before our log message, you'll see these messages.

That's the GET request our browser made to load the edit form.

See the parameters line there?

That shows the contents of the params hash.

We see an id key, but no pet key.

Aha, there's our problem.

We were supposed to use params ID when calling pet.find, not params pet.

So let's go back into the pets controller and fix that.

We'll remove the log message, save our work, and reload the page.

Now that we're using a parameter that actually exists,

the pet record is found successfully and the error is gone.

The Rails logger can be a useful tool for

debugging your apps in other situations, too.

See the teacher's notes if you'd like more info on it.