AppleScript_ The Definitive Guide - Matt Neuburg [162]
try
repeat
set end of L to name of disk x
set x to x + 1
end repeat
end try
end tell
L -- {"feathers", "gromit", "Network"}
In the second, fuller form of try block, you supply a second block, an error block , presumably containing some error-handling functionality:
try
-- code in which errors will be caught
on error [parameters]
-- error-handling code
end try
If an error is occurs within the try block (the part before the error block), the try block terminates; execution resumes at the start of the error block. If no error occurs in the try block, the error block is skipped.
If an error occurs within the error block, it is not caught by this try block, because we are past that already; but it might be caught by some other try block that we are nested inside, either directly or further up the calling chain. Indeed, it is perfectly legitimate, and possibly useful, to throw an error within an error block.
The parameters of an error block are exactly the same as those for an error command, so your error block can capture and respond to any information that may have been included when the error was thrown. You don't have to include any parameters and you can include any subset of the parameters; thus you aren't forced to capture information you don't care about. Parameter variable names are local to the error block .
A not-uncommon technique is to include all the parameters and rethrow the very same error, or a slightly modified version of it, from within the error block. This could be a way, for instance, to shut things down in good order before letting the error percolate all the way to AppleScript and display a message. It can also be a way to tell yourself more about where the error occurred:
on num(what)
try
return what as number
on error s number i partial result p from f to t
set s to "Handler num got an error: " & s
error s number i partial result p from f to t
end try
end num
num("howdy") -- error: Handler num got an error: Can't make "howdy" into type number
Error handling and error throwing can be the basis of useful flow control. You can do some powerful things with errors that can't easily be accomplished in any other way. You can also structure your scripts better through the use of errors.
In this example, flow control is implemented entirely through handler calls and errors. We ask the user for a number; if the user tries to cancel, or supplies something that can't be coerced to a number, AppleScript throws an error, and we start over recursively. The error thrown at the end of the askUser handler is a trick for returning the user's number directly without unwinding the entire recursion:
on askUser( )
try
set x to text returned of ¬
(display dialog "Give me a number:" default answer "")
set x to (x as number)
on error
askUser( )
end try
error x
end askUser
try
askUser( )
on error what
display dialog "Your number is " & what
end try
This next example is somewhat similar: it asks the user to enter the name of a color, and persists until the user complies. (In this example, unlike the previous one, if the user cancels, the script politely stops.) The example demonstrates how errors and error handling can help you organize the structure of a script:
on getFavoriteColor( )
try
set r to display dialog "What is your favorite color?" default answer ""
on error
error number 1001
end try
set s to text returned of r
if s = "" then error number 1000
return s
end getFavoriteColor
set c to ""
repeat until c is not ""
try
set c to getFavoriteColor( )
on error number n
if n = 1000 then
display dialog "You didn't enter a color!" buttons "OK"
else if n = 1001 then
display dialog "Why did you cancel? Tell me!" buttons "OK"
end if
end try
end repeat
display dialog "Aha, you like " & c & ", eh?"
In that example, the handler getFavoriteColor has just one job—to try to get the user's favorite color and report what happened. Either it returns the user's favorite color, or it throws error 1000 to signal that the user left the field blank in the dialog,