I’m working on a script to collect and rearrange data from a number of text files.
The basic find routine was simple enough:
try
set AppleScript's text item delimiters to someString
-- text manipulation here
set AppleScript's text item delimiters to ""
return theresult
on error errStr number errNum
set AppleScript's text item delimiters to ""
return ""
end try
Now I’m encountering cases where I must consider case.
So I just added that, without considering the ramifications of what I was typing:
try
considering case
-- preexisting code
end considering
return theresult
on error errStr number errNum
end considering
set AppleScript's text item delimiters to ""
return ""
end try
That doesn’t compile, of course.
So what happens, after an error in the considering block? Considering case is now on: does that affect only this script, or all of AppleScript?
For the case in hand the one anticipated error is absence of the search string (which is case-sensitive).
But random errors?
No need to worry about it. When the flow jumps out of the ‘try’ section, it jumps out of the ‘considering’ statement too.
try
considering case
set caseConsidered1 to ("a" is not "A")
error
end considering
on error errStr number errNum
set caseConsidered2 to ("a" is not "A")
end try
{caseConsidered1, caseConsidered2} --> {true, false}
Do you really have to have that end considering case block as the first statement in your on error block?
Another go could be to have all the error handling within the considering case block to be sure it is turned off? (I’d try that!
If I were you, I’d just write a couple of tests, to see if the considering case is on afterwords, and have some code inside your block that fail deliberately.
I wrote a script to show that your end considering doesn’t need to be inside your on error block. The considering is turned off even if you error within it. I think, and firmly believes that what happens when you enter an on error block, is that the stack pointer is pushed down (in C-terms, and the program loads another stack, where your error is processed, before the original stack is pushed back on. Therefore the considering block will end before you enter the errorprocessing part anyway. This can also lead to funny results if you start to process stuff with local variables inside your on error block!
set a to "Food"
set b to "food"
try
considering case
if a = b then
log "alike"
else
log "unlike"
end if
set a to c
end considering
on error e number n
log "failed"
end try
if a = b then
log "alike"
else
log "unlike"
end if
My conclusion is that you can process errors like you normally do.
I won’t discuss this, but I find my approach more readable. :D. As long as nothing else is going on I prefer this construct, because the exit is then close to the on error block. I can’t say that your preferences are wrong or any thing, just that the way the construct is made is according to my personal taste.
Now, if there was a do while loop here, then I would have agreed with you, but there isn’t.
The other thing is that I know can keep the failed variable local within that scope, that is not a big deal really, but I use that name a lot, and then this lessens the confusion, as to what value the failed variable may have, or not have in other parts of a script.
That is the best solution, as long as there aren’t any post processing due to the fail. What can I say, I am lazy, and there usually is some postprocessing, when an error has occured. We are talking muscle memory here, inside an example snippet.
It would also be better do deal with success than fail, I have pondered about that, and thinks it to be a human treat, to more easily perceive failure than success!
Edit I think Nigel Garvey’s to be the most efficient one, when you don’t need post processing. But for clarity and readability I think it is best to have a variable indicating it. It is really all about who is going to read it, and mileage may vary. and the size of an actual block of code of course. Every thing becomes easier to comprehend when the code block is small.
I just thought of a solution, and posted it, as someone may find it handy, at least I did.
. I’m not saying yours is wrong either, just a personal taste. Maybe it’s because I’m writing lower level and used to old coding.