Personally, I favor the triad as it is common in languages such as Java or the .NET family. And that's why I used it extensively in Quartam PDF Library, throwing errors whenever something was wrong. Some people find this annoying, I feel that it keeps my code cleaner as there is no error checking all over my script, obfuscating what I'm really trying to accomplish.
The important thing to remember is that revTalk is a language which mixes the approaches: for a command like 'open file' you must check the result to see if it failed by any chance. However, if you try to set the 'angle' of an image to "foobar" it will throw an error as "foobar" is not an integer. It's probably due to the HyperCard heritage, where there was no try-catch-throw triad, but it's an inconsistency I'd rather see cleaned up.
Anyway, here's an example to get you started with the try-catch-throw paradigm. Just create a new stack, add a field named 'Log' and add a button with the following script:
on mouseUp
try
Foo
catch tError
Log "mouseUp: running catch block"
answer error tError
finally
Log "mouseUp: running finally block"
end try
end mouseUp
command Foo
try
Bar
catch tError
Log "Foo: running catch block (" & tError & ")"
finally
Log "Foo: running finally block"
end try
if tError is not empty then
Log "Foo: rethrowing error (" & tError & ")"
throw tError
end if
end Foo
command Bar
Log "Bar: before calling Snafu"
Snafu
Log "Bar: after calling Snafu"
end Bar
command Snafu
answer "Continue, throw or exit to top?" with \
"Continue" or "Throw" or "Exit to top"
Log "Snafu: user picked (" & it & ")"
if it is "Throw" then
throw "Snafu: user decided to throw"
else if it is "Exit to top" then
exit to top
end if
end Snafu
--
private command Log pText
put pText & return after field "Log"
end Log
Click the button and pick the option 'Continue' - the following text should be in the log field:
Bar: before calling Snafu
Snafu: user picked (Continue)
Bar: after calling Snafu
Foo: running finally block
mouseUp: running finally block
As you can see, everything went smoothly, and the code in the finally blocks of both the Foo and mouseUp handlers were called. This is where you should handle any cleanup (such as closing the database, files, cursors,...)
Now click the button again and pick the option 'Throw' - the following text should appear in the log field:
Bar: before calling Snafu
Snafu: user picked (Throw)
Foo: running catch block (Snafu: user decided to throw)
Foo: running finally block
Foo: rethrowing error (Snafu: user decided to throw)
mouseUp: running catch block
mouseUp: running finally block
As you can see, the throw in the Snafu handler caused the catch block to be executed in the Foo handler, followed by its finally block. In this case, I decided to re-throw the error after the try block of the Foo handler, so that the catch block in the mouseUp handler would also be called, automatically followed by its finally block. Note that the Bar handler was immediately interrupted so no 'after' log line was written.
Now click the button once more and pick the option 'Exit to top' - the following text should appear in the log field:
Bar: before calling Snafu
Snafu: user picked (Exit to top)
Yes, that's right, this means that execution halts completely, and not even the finally blocks in the Foo and mouseUp handlers are called.
This last bit teaches us to be cautious and not try and mix the different approaches to error handling without testing out the consequences.
