Re: How to exit ?
Re: How to exit ?
- Subject: Re: How to exit ?
- From: email@hidden
- Date: Tue, 28 Aug 2001 22:57:45 -0400
On Tue, 28 Aug 2001 13:41:55 +0200, Ian Mantripp <email@hidden> suggested,
>
>> I would set up a separate exit subroutine somewhere in the script, then
call
>
>> the subroutine when needed.
>
>
> Yes, how would that exit handler look like?
>
Something like :
>
>
quit
>
>
on quit
>
display dialog "Sure ?"
>
if the button returned of the result is "OK" then continue quit
>
end quit
Once again, a scripter falls for the lure of the "quit" command. Like a mirage
in the desert, the water evaporates when you arrive.
Try this script. Save it as an applet, and give it 800K of memory so that won't
give an "out of memory" error on the "say" command.
say "I"
quit
say "quit"
Run this, and you'll hear "I quit"
The reasonable detail is that the way the applet shell handles the quit command
is to quit once its done with the current handler call. A quit command (whether
from another application or from itself) to the applet shell won't stop the
script in the middle of execution, it will instead cause the applet shell to
quit when the executing handler returns to the shell. Now, if it wasn't saved
as "Stay Open", there is no real effect, because the shell will exit when the
current handler returns anyway.
Now, to the root of the problem: how to quit from inside the middle of a deep
nested set of handlers. There are three separate cases where this might be
desirable. Two are legit, in my opinion, and the third is probably best handled
with a step-by-step return.
Situation 1 is an unexpected error. This is an exceptional case, and causes a
break in the normal flow of function call and return. AppleScript's 'error
"blah blah" number n' does this.
Situation 2 is a user-directed termination of the program. It is also an
exceptional condition. It can be handled like an error, specifically with error
-128, "User canceled."
Situation 3 is a normal completion of the action of a function or object. In
this case, the object or function should return to its caller, and let the
caller decide whether to stop processing or to do something else. If you make
your function or object terminate the script out from under its caller, you make
the script much less useful. The function or object should encapsulate an
action or process--if it interrupts the flow of its caller, it messes up that
encapsulation, interfering with the caller's ability to do what that caller is
trying to do.
To get more specific: If you tell an inner-level function that if it hits the
end of file, (or the end of a list, or a zero value) it should exit the script,
you build information about the meaning of end-of-file into that low level
function, and the higher level script can't define what the meaning is, and
can't use the function if the higher level script wants to do something else.
Certainly, if you are throwing together a script, and haven't thought about all
the special cases you might run into, you may not have defined return values
that explain what happened to the caller. And I'll admit, there is something
very dissatisfying about the C and Pascal convention that the value returned by
a function often merely tells you how something turned out, while the actual
work is done as a side effect. Generally, I've found script objects allow me to
avoid much of this either/or behavior, because the result goes into the object,
rather than being returned from a function. AppleScript also allows you to
return complex structures and dynamically typed results, so you can return
"missing value" if there is a non-fatal problem, or return a record containing a
string and the number of characters read at the same time.
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden