• Choose a category
• All
• Classic-Fiction

The class item

You can use any of the parameters when throwing an error, but in real life you are likely to use only the first two. The others are present because this is also the structure of an error message from an application, which can supply this further information to help explain what the problem was.

If you throw an uncaught error, it will percolate all the way up to AppleScript and will be presented to the user as a dialog . The messageString is your chance to dictate what appears in that dialog. You will probably want to say something meaningful about what went wrong. For example:

error "Things fall apart, the centre cannot hold."

Figure 19-1 shows how that error is presented to the user in the Script Editor.

If an error is thrown in an applet, the applet puts up a similar dialog, which also offers a chance to edit the script. If this is a Stay Open applet ("Applet Options" in Chapter 27), the error does not cause it to quit.

If you don't supply any parameters at all to your error command, the error dialog reads: "An error has occurred." If you don't supply a messageString but you do supply an error number—let's say it's 32—the dialog reads: "An error of type 32 has occurred."

Figure 19-1. An error dialog

An error number is not highly communicative to the user, unless the user happens to have a table of error numbers and their meanings, but it is certainly useful within code, particularly when you're implementing internal error handling. If different kinds of things can go wrong, you can use this number to signal which one did go wrong. An example appears in the next section.

Error number -128 is special. If an error with this number percolates up to AppleScript, the script stops but no error dialog is displayed. This is the error number generated when the user presses Cancel in a dialog presented by an interface scripting addition command such as display dialog. Thus, the user can cancel without automatically being presented with an error message immediately after. ("User canceled." "I know that!")

Some milieus never present an error message, regardless of the error. For example, if a script being run by Apple's Script Menu generates a runtime error, the script will simply fail silently. I regard this as a bug.

Catching an Error

The only way to catch an error is for that error to be thrown within a try block . The thrown error percolates up through the call chain , and if it eventually finds itself within a try block, it may be caught. The point of the call chain here is that the error need not occur directly within a try block; it may occur within in a handler that was called within a try block, or the call to that handler may be within a try block, and so forth.

There are two forms of try block. In the first, there is no actual error-handling code:

try

-- code in which errors will be caught

end try

This form of try block handles the error by ignoring it. If an error occurs within the try block, the block terminates; execution resumes after the end try, and that's the end of the matter. Thus, you have no way to learn directly that an error was caught (though you can learn indirectly, because some code may have been skipped). But at least the error didn't bring your script to a halt. Here's an example:

set x to "Cancel"

try

set x to button returned of (display dialog "Press a button.")

end try

display dialog "You pressed " & x

Without the try block, this code would never reach the last line after the user presses the Cancel button.

In this next example, we use a try block as a form of flow control, to terminate a loop prematurely (see "Looping," earlier in this chapter). We want to get the name of every disk. (Ignore the fact that we could just ask the Finder for this information directly.) Instead of asking how many disks there are and looping that number of times, we loop inside a try block. The loop is ostensibly endless, but in actual fact, when we exceed the number of disks, the Finder throws an error and the loop ends.

set L to {}

set x to 1

tell application