Everyone makes mistakes; some of us more than others. When you make a mistake in AppleScript, AppleScript will let you know about it by displaying an error message. Let’s raise an error. Open Script Editor and type:
say moose
Now run the script. (You remember how to run a script, right? Command+R or click the “Run” button.) Whoa! A sheet drops down from the Script Editor window that looks like this:

Why did we get an error? Well, as we recall, the say command wants a text object as an argument. Text objects are ordered Unicode characters with quotation marks around them. Here, we forgot the quotation marks, so AppleScript translated the word “moose” into a variable rather than text and raised an error.
#### Deal with it
To deal with errors, AppleScript includes a try…on error…end try statement to trap errors and allow your program to handle those errors as needed. Let’s use the example above to demonstrate the try statement. In Script Editor, type:
try
say moose
on error errorMessage
display dialog errorMessage
end try
There’s a lot to digest in those five lines. Let’s start with line 1. In line 1, we tell AppleScript that we’re going to “try” all the statements up to the “on error” statement. Essentially, you are setting up AppleScript to catch any errors in your script. Oftentimes, you will have multiple try statements in a script.
Line 2 looks familiar: it’s our statement from above that generated the error. We’ll keep it the same because we want to see the effect of the error in this setting.
Line 3 includes a statement “on error” followed by a parameter “errorMessage”. When AppleScript raises an error within a try block, the “on error” message captures the error in the “errorMessage” variable. (A variable is just a named container where you store a value. You store a value in a variable, then you can refer to the value over and over again by requesting the variable.) Once you capture the error, you can do something with it. Most errors have error codes (-2753 in this case), so you can do one thing if errorMessage equals a certain code and you can do something else if errorMessage equals a different code. You can also exit the script or continue the script despite the error. Sometimes you want to raise an error so that you can force something to happen. Here we’re going to display a dialog box as shown in Line 4.
Line 4 shows a common way to display information to a user with the display dialog command. We’ll discuss the display dialog command later, but you should know that it pops up a window and displays the text shown in the first parameter, here, errorMessage.
Line 5 tells AppleScript that we are at the end of our try block. You must include “end try” at the end of the try block.
Run the script. You should see a dialog box pop up like the one below:

What happened? AppleScript tried to execute “say moose”, but as we saw above, because the word “moose” did not have quotation marks, AppleScript raised an error. We captured the error in errorMessage (line 3) and displayed errorMessage to the user (line 4).
We will be using the try statement in almost all of our scripts so please review this post again if you’re not sure what we did. In our next post, we’ll begin scripting the Finder. Until next time, happy scripting!
#### Extra! Extra!
So, what do you think happens when you type the following into Script Editor?
say 4
We have the say command followed by an integer. We know that the say command requires text as an argument, not an integer. If you run the script, however, your computer will speak the word “four”. I already hear you saying, “But you said that if we don’t provide the right argument, then AppleScript will raise an error.” Yes, but before raising an error, AppleScript often tries to help you out. And here, AppleScript helps you out by coercing the integer, 4, to a text object, “4″, before executing the say command. AppleScript will only coerce one class to another if you could have coerced the class on your own. Here, you could have written “say (4 as text)” and the script would have run properly. Otherwise, AppleScript will raise an error as shown in our first example.
The Elements of Finder | Scripting for Lawyers on March 19th, 2008 at 19:09 says:
[...] In the Result pane, you should see the name of your hard drive. (Mine is “Macintosh HD”). So what did we do? We told the Finder to get the name property of the first disk object. Although we didn’t see the “name” property in the property definition for “disk”, AppleScript found it by looking up the inheritance chain until it found a “name” property, then returned the name to us. If we asked for a property that was not in the inheritance chain, then AppleScript would raise an error, which, of course, we would handle properly [...]