Alternative to Try/Catch Control Statement

[townsend]

The Try/Catch control statement works great for catching unrecoverable errors.

Code: Select all

try
    open file tFile
    read from file tFile until eof
    close file
catch someError
     answer "An error occurred reading a file" && someError
end try

But-- is there anything more generic? By adding, try/catch/end try, to every IO and DB statement,
it seems like a lot of extra code is being duplicated unnecessarily.

Is there any other way to catch unrecoverable errors? Maybe at the card or stack level,
to get my error reporting code all into one handler?

[Mark]

Hi,

Particularly in standalones, you might use the errorDialog message. The difference with try-catch is that a script doesn't necessarily halt if the error occurs inside a try-catch statement while it will if you just use the errorDialog message.

Kind regards,

Mark

[townsend]

Yes, I understand. The Try/Catch is good to catch and recover from an error, while the errorDialog offers no recover options. That's perfect. Because I'm looking for some kind of report, when all else fails.

I've studied the errorDialog docs, but am still very confused. I can't seem to get the sample errorDialog handler fire.

Code: Select all

on errorDialog pExecutionError, pParseError
      answer "An error occurred on line: " & item 2 of line 1 of pExecutionError
end errorDialog

I've switched off the Script Debug mode but then I only get:

141 errors box.png (5.22 KiB) Viewed 8566 times

This is just what I'm looking for, but it does not show up when the the executable fails.
And, I know, this has nothing to do with the errorDialog handler.
In regard to the errorDialog. I'm paticularly confused by this statement.

If the lockErrorDialogs property is true, the errorDialog message is sent to the object that set the lockErrorDialogs., rather than to the object whose script contained the error. (The lockErrorDialogs can be set to true either by setting the property directly, or with the lock error dialogs command.)

[townsend]

And then I enabled the Bug Reports option on the Standalone Application Settings and I got this report:

Executing at 9:45:55 AM on Friday, November 4, 2011
Type: if-then: error in statement
Object: stack "revExternalLibrary" of stack "Z:/temp/DataKeeper/Windows/DataKeeper.exe"
Line:
Line Num: 0
Hint: revExecuteSQL

Comments: none

Which is totally useless.

[Mark]

Hi,

In a fresh session of Revolution (LC) I created a new stack with a one button. Button script:

Code: Select all

on mouseUp
  dffdfdfdfds
end mouseUp

on errorDialog x,y
  beep
end errorDialog

I turned off Script Debug Mode and it worked for me.

That's all I can say about it. It should work. Please try this and then try it again with your database script.

Best,

Mark

[townsend]

Yes-- I see. It works well for syntax errors, and probably other errors as well.
But it looks like revExecuteSQL errors are the exception.

Code: Select all

on mouseUp
     local dbID, SQL
     revExecuteSQL dbID, SQL
end mouseUp

on errorDialog pExecutionError, pParseError
      answer "An error occurred on line: " & item 2 of line 1 of pExecutionError
end errorDialog

This code produces the IDE Error message, as pictured above. And-- in the executable-- nothing.

Thanks for your help on this Mark. Any other suggestions?

[Mark]

Hi,

I have seen this problem with the database library happen many times. I think the error is thrown by something inside the external that connects to the library. It jut throws an error but doesn't provide any information about the cause of the error or the location where it occurred.

I can only say, get your code right until this error doesn't occur anymore. There is probably something wrong in either the way you connect to the library or in your code. Make sure your connection/database actually exists and that your syntax is correct. Also make sure that collations are correct.

You might want to post the SQL code causing the error.

Best,

Mark

[townsend]

I've been intentionally causing this error, by doing DB operations, without first opening.
Like I said, I was looking for a when-all-else-fails report.
SO-- it looks like revExecuteSQL errors can only be captured with a Try/Case statement.
If I find any other exceptions, I'll report back here.

Thanks again Mark.

[mwieder]

OK - a few things here:

First of all, a try/catch construct will take precedence over a thrown error. That's by design, as it allows you to handle errors locally before control gets handed off to the more generic error-handling routines.

Secondly, you may want to stick with the try/catch handlers, as there's a big difference in the way try/catch and errorDialog processing takes place: try/catch will allow you to deal with the error yourself and continue processing if so desired. Throwing an error to the errorDialog process stops the execution of the running script.

Also, note that you can throw an error in a catch construct in order the have the error bubble up to the caller of the handler that caused the error.

Third, I got successful results from the following, but I've found that lockErrorDialogs seems to be sticky (restarting the IDE cleared things up and got the first example here working after it stopped responding):

Code: Select all

    on mouseUp
         local dbID, SQL

         revExecuteSQL dbID, SQL
    end mouseUp

    on errorDialog pExecutionError, pParseError
          answer "An error occurred on line: " & item 2 of line 1 of pExecutionError
    end errorDialog

which displays the answer dialog correctly.

Code: Select all

    on mouseUp
         local dbID, SQL

         try
            revExecuteSQL dbID, SQL
         catch e
            answer "caught" && e
         end try
    end mouseUp

which again displays the answer dialog correctly.

Also, earlier you posted

And, I know, this has nothing to do with the errorDialog handler.

as a comment to turning off Script Debug Mode and hitting an errorDialog routine. Actually that has everything to do with errorDialog. That's the IDE's builtin errorDialog handler in action. If you turn on Script Debug Mode you'll end up in the script editor debugger with the errant line highlighted. In a standalone you won't have the IDE available, so if you want to see the errors you'll have to set lockErrorDialogs to true in order to trigger your errorDialog handler.

[townsend]

Thanks for chipping in here Mark. I wasn't able to get the errorDialog to fire
on a revExecuteSQL error, even when trying variations of these commands:

Code: Select all

--lock error dialogs
--unlock error dialogs
set lockErrorDialogs to true

Maybe that's because I'm still running version 4.6. Oh well...
I'll just have to take some extra precautions with the revExecuteSQL command.

THOUGH-- thanks to everyone's help-- I have made quite a bit of progress
on my if-all-else-fails handler. Here's the code.

In the code area of each Card, and at the end of every Button script I add:

Code: Select all

on errorDialog
     pass errorDialog
end errorDialog

Then in the Stack Code I put:

Code: Select all

on errorDialog pExecutionError, pParseError
     put pExecutionError
     if pExecutionError > empty then
          answer "An error occurred on line: " & item 2 of line 1 of pExecutionError \
                & cr & "In hander: " & item 4 of line 3 of pExecutionError \
                & cr & "In Script: "  & item 4 of line 4 of pExecutionError \
                titled "Execution Error"
     end if
     if pParseError > empty then answer pParseError titled "Parse Error"
end errorDialog

Which produces this error dialog any time a unrecoverable error occurs.

Note to any developer who is planning on deploying their app to a wide audience. If your app crashes without code like this, you'll have little or no clue what to do. Why panic? All you can do-- is add in code like this-- quickly-- and release an update. Then you can fix the problem and release another update. So-- It's a lot easier to just to have this kind of Error Report code in there, from the start.

[mwieder]

The LC version shouldn't matter. I tested this with 4.6.4, since it's more stable and robust than 5.0.

Get rid of the

Code: Select all

    on errorDialog
         pass errorDialog
    end errorDialog

code. That does absolutely nothing.

I put an errorDialog handler in the stack script of a test script of a standalone application and it did a nice job of catching all the unhandled errors: a button script of

Code: Select all

on mouseUp
  dfdf
end mouseUp

generated a nice answer dialog. No lockErrorDialogs statements anywhere, Bug Reports unchecked in the Standalone Settings for the stack. That by itself should take care of your last-resort error handling *in a standalone*. In the IDE the debugger frontscript should grab the errorDialog message before your stack does.

...and... if you really need to debug standalone applications in the wild beyond just generating a canned error text message, you should check out PowerDebug... trial version on revOnline or (somewhat dated) demo at

http://www.ahsoftware.net/PowerTools/Po ... DDemo.html

[townsend]

Thanks for pointing that out Mark-- you're right.
The pass errorDialog statements are unnecessary.

My when-all-else-fails errorDialog handler has been updated to also,
paste the error info into the clipboard. It now looks like this.

Here's the code which only exists in one place-- in the Stack Script.

Code: Select all

on errorDialog pExecutionError, pParseError
     local look
     if pExecutionError > empty then
          put the internet date & cr & \
                "An error occurred on line: " & item 2 of line 1 of pExecutionError \
                & cr & "In hander: " & item 4 of line 3 of pExecutionError \
                & cr & "In Script: "  & item 4 of line 4 of pExecutionError & cr & cr \
                & "Please email clipboard ERROR  text to: me@mydomain.com" & cr into look
          set the clipboardData to look; beep
          answer look titled "Execution Error (pasted into clipbpoard)"
     end if
     if pParseError > empty then 
          put cr & "Parse Error:" & cr & pParseError after look
          set the clipboardData to look; beep
          answer pParseError titled "Parse Error (added to clipboard)"
     end if
end errorDialog