The errorDialog message can be tricky to work with, because the error strings aren't passed as params but merely referenced by a line number which corresponds to a list tucked away in a property in Rev's "Execution Error" stack. You can obtain it if needed, but it should be very rare that you would need to do so.
Rev traps errors with its Execution Error dialog in the IDE, and by default includes that dialog in standalones as well. Since it's triggered only for those errors you hadn't already accounted for, ideally your users should never see it, or at least very rarely.
Long before a situation results in an error you can anticipate and handle them more gracefully. Indeed, it's been estimated that nearly half of all code in most apps deals with anticipating errors and providing graceful degradation from them.
For example, if you're writing a file any number of things can go wrong: Is there any data to write? Is the file already open by another app? Is there a file with the same name in that location already? Each of these can be anticipated and handled in advance, so your user doesn't have to deal with a generic error dialog:
Code: Select all
on SaveFile pData, pFile
-- Check if data exists:
if pData is empty then
answer "No data to save."
exit to top
end if
--
-- Check if file exists:
if there is a file pFile then
answer "There is already a file ""e& pFile"e
exit to top
end if
--
-- Attempt to write file:
put pData into url ("binfile:"& pFile)
-- Check the result for errors:
if the result is not empty then
answer "Couldn't write data file ""e& pFile"e &cr\
&"("& sysError() &")" -- sysError shows the error code from the OS
end if
end SaveFile
So while the actual writing of the file is just one line, we have 11 other lines checking errors and providing useful information to guide the user toward a resolution.
Anticipating and handling possible error conditions, coupled with thorough testing, should obviate the need for handling the errorDialog message directly. And if something falls through the cracks, Rev's Execution Error dialog can handle those well, even providing a mechanism so folks can email the error data to you in a readable form.