Re: Quitting from an idle handler
Re: Quitting from an idle handler
- Subject: Re: Quitting from an idle handler
- From: "Gary (Lists)" <email@hidden>
- Date: Mon, 08 Aug 2005 19:05:58 -0400
"Gil Dawson" wrote:
> At 8:02 AM -0400 8/8/05, J. Stewart wrote:
>> I must admit to being a bit curious as to why you would want/need to
>> write a custom error handler when there is a built in construct that
>> will usually do a better job of it. Try - on error's sole purpose is
>> to deal with errors. It can notify, ignore, supply alternative
>> methods and of course, bail out.
>
> Sometimes I need a little guidance seeing new ways of doing things.
Hear, hear. (Or is it 'here, here'...Chris Nebel...?)
> It makes elaborate tests inside the subroutines to ensure that all is
> ready for the next step. If any test fails, I would like it to put
> up a dialog and wait (perhaps hours) for the user to see it. When
> the user OKs the dialog, I would like the program to quit.
>
> My strategy for implementing this scenario is to make all the tests
> on their failure branch call a single subroutine that puts up a
> display dialog then calls error number -128.
This description sounds a bit confusing (and conflicting), but I think I get
your drift. You don't want each failure to put up a dialog (like you say in
the first paragraph), but rather for each failure to pass its failure
conditions onward (like you say finally).
A number of AppleScript user interaction commands (display dialog, choose
file, etc.) return a -128 when the user clicks 'Cancel'. That's what
generates the error and the error code.
You don't specifically "call" (although you can, I suppose) "error number
-128". Passing it along is quite appropriate, however.
> What would you suggest?
Set up your "try...on error...end try" so that it captures all of the error
data that AppleScript provides, then pass those results along to your
special-purpose error sifting handler.
Let that handler take whatever action you need, controlling what happens
next in the script.
The 'on error' structure provides for the ability to capture some
parameters, too. Namely the error number and the error message.
Some examples, including not trapping at all versus passing along some or
all of the information generated by an error.
-- Ex. 1 : Do nothing.
try
"HD:file.txt" as alias
end try
--> nothing, no error handling
-- Ex. 2 : Get the error number and display it to user
--
try
"HD:file.txt" as alias
on error number n
display dialog n
end try
--> AS dialog saying: -43
-- Ex. 3 : Get the error number, but pass it along
--
to handleErrorVer1(n)
if n is -43 then display dialog "You idiot!"
end handleErrorVer1
try
"HD:file.txt" as alias
on error number n
handleErrorVer1(n)
end try
--> AS dialog saying: You idiot!
-- Ex. 4 : Get the error number and message
--
to handleErrorVer2(n, m)
if n is -43 then
display dialog "You idiot!"
else
display dialog m & " [" & n & "]"
end if
end handleErrorVer2
try
"HD:file.txt" as alias
on error msgtxt number numcode
handleErrorVer2(numcode, msgtxt)
end try
--> AS dialog saying ...
--
Gary
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden