Error Context (used to be Inheritance)
Error Context (used to be Inheritance)
- Subject: Error Context (used to be Inheritance)
- From: "Wallace, William" <email@hidden>
- Date: Wed, 21 Jan 2004 14:01:34 -0600
- Thread-topic: applescript-users digest, Vol 3 #2343 - 12 msgs
Thanks Axel, that does clarify things for me.
>>p's suggestIt()
>>z --> 4?
>>
>>Shouldn't that work as well, or am I missing some aspect of this concept?
>>
>IMHO, it should set z to 4.
>And just to be sure, I tried your code here; z is set to 4.
>Now, I'm not sure what the interrogation mark in "z --> 4?" is for.
>Did you get error messages and/or unexepected results? And, if yes,
>which ones?
>
The question mark at the end of "z --> 4?" just meant that I was guessing at the result but hadn't actually tested the code yet. I'm still pretty green when it comes to scripting, and I've been known to accidentally devise test code that yields the expected result but for the wrong reason. So I like to get the opinion of someone with experience in addition to doing my own tests.
>
>In fact, it could be said that a "try" statement pushes an error
>context, and that the corresponding "end try" statement pops that
>context. If the error context stack is empty when an error occurs, the
>script halts immediately; otherwise, the context at the top of the stack
>would be used.
>So, your idle's try block can't claim seniority upon a narrower try
>block if there is one.
>On the other hand, an error can "bubble up" only through statements
>between the "on error" and "end try" statements of the nearest enclosing
>try block; a stupid example:
> ... -- while executing statements
> try -- one encounters a try block
> set x to 1/0 -- jump immediately to "on error"
> on error
> set x to 2/0 -- it depends...
> end
> ...
>Of course, instead of that idiotic "set x to 2/0", you could have a call
>to some script's handler or something even more complicated. The
>question is to know whether, in case of a subsequent error, a try
>statement would be encountered before the erroring statement or not;
>and, if not, whether there is a pending error context or not.
This is really the heart of the issue I was trying to sort out. I was concerned that I was setting myself up for and infinite error loop or at least a difficult to debug string of nested errors. As it turns out the point is moot for the moment.
For example:
--main script
global scriptVar1, scriptVar2, errNum, errMsg
set scriptVar1 to (load script alias "path:to:script1")
set scriptVar2 to (load script alias "path:to:script2")
try
set p to 1/0
on error errMsg number errNum
tell scriptVar1 to doSomething(errNum, errMsg)
display dialog "Main Error! " & errNum & return & errMsg
end try
--loaded script 1
on doSomething(myNum, myMsg)
try
set myBungle to myNum/0 & myMsg
on error errMsg number errNum
tell my parent's scriptVar2 to doSomethingElse(errNum, errMsg)
display dialog "Script 1 Error! " & errNum & return & errMsg
end try
end doSomething
--loaded script 2
on doSomethingElse(theNum, theMsg)
try
set myFauxPas to (myMsg /(myNum/0))
on error errMsg number errNUm
display dialog "Script 2 Error! " & errNum & return & errMsg
end try
end doSomethingElse
What I would have hoped would happen here is that I would get three dialog boxes in a row, each with their appropriate error number and error message. What I was afraid I would get was three dialog boxes each containing the "Script 2 Error". What I actually get is "Exectution Error! scriptVar2 doesn't understand the doSomethingElse message". So I still don't have a firm grasp of this concept it seems. Can you show me where I've gone wrong in the above?
>Finally, the idea of putting the whole error treatment into a single
>handler would somewhat go against the idea of modularity provided by
>script objects. But this is just an opinion...
That isn't really what I'm doing. Let me clarify. In the on error section of my try blocks there is different code depending on the situation. However, in _every_ case there is a call to a specific handler that logs the error in a text file and sends me an email alert that an error has occured. The email alert is actually achieved by a call to yet another handler whose sole purpose is to send the email. I broke it up like this because I use the same email alert handler in the event that the script ever completes a successful job (an increasingly remote possibility) to notify me of the success.
>HTH,
>Axel
Anyway, thanks for your insights.
-B!ll
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.