• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Desperately seeking an error
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Desperately seeking an error


  • Subject: Re: Desperately seeking an error
  • From: Paul Skinner <email@hidden>
  • Date: Wed, 22 Aug 2001 10:29:46 -0400

on 8/20/01 2:11 AM, Jon Pugh wrote:

> At 11:44 PM -0400 8/19/2001, Paul Skinner wrote:
>> try
>> --some code
>> on error errorMessage number errorNumber partial result errorResult from
>> errorFrom to ErrorTo
>> set theResults to {handlerName:handlerName, errorMessage:errorMessage,
>> errorNumber:errorNumber, errorResult:errorResult, errorFrom:errorFrom,
>> ErrorTo:ErrorTo}
>> end try
>>
>> I understand that all of these pieces of data may be generated by an
>> error. Can anyone tell me of an instance where all of these pieces of data
>> are not generated by an error?
>
> Most of the time only one or two of these items are generated. Normally, just
> one, the error number, is supplied and AppleScript will construct the rest of
> the values as it can. For example, it knows most of the standard file system
> errors, as well as common system error codes, like memory for example. This
> allows applications and scripting additions to just return common errors,
> hopefully supplying the offending object when it is not the direct parameter.
>
> After an error is returned, AppleScript guesses on the values that weren't
> supplied, and once you declare them in your error handler they HAVE to be
> initialized with a value since AppleScript doesn't really have the concept of
> an uninitialized variable.
>
> Jon

I wish. AppleScript can have undefined variables. They generate those
"Variable 'blah' is undefined" errors that I get from time to time.
You'll have to supply valid values for all of the following variables to
test this.
userName, userPassword, ipAddress, volumeName.

--begin script
try
mount volume ("afp://" & userName & ":" & userPassword &
"@" & ipAddress & "/" & volumeName & "/")
on error errorMessage number errorNumber partial result
errorResult from errorFrom to errorTo
return {handlerName:handlerName,
errorMessage:errorMessage, errorNumber:errorNumber, errorResult:errorResult,
errorFrom:errorFrom, errorTo:errorTo}
end try
--end script

In this example both errorResult and ErrorTo {} but errorFrom is
undefined! And of course none of it gets returned because there is an error
in the 'return' statement. You can log it or try-wrap it to see the values.
Bugger! Now I'll have to pre-define them.
Of course this script fails here for some unknown-as-of-yet error. If it
works for you you won't see the problem I'm trying to demonstrate. But take
it from me. 'on error' may not fill in all of the blanks.

--
Paul Skinner
PowerBook G3 Series
400 MHz
9.1 US
AppleScript 1.6
CarbonLib 1.3.1


References: 
 >Re: Desperately seeking an error (From: Jon Pugh <email@hidden>)

  • Prev by Date: Re: run script
  • Next by Date: Current paragraph # in quark text box
  • Previous by thread: Re: Desperately seeking an error
  • Next by thread: Variable to an application keyword
  • Index(es):
    • Date
    • Thread