On Error Goto 0

[Blake]

Is there any reason ever to use:


On Error Goto 0


before exiting a function/script/event handler? The error-handling seems to get reset on exiting, and I really can't imagine how it could persist.

It would be nice, of course, to be able to have global error-trapping/exception-handling that you could use, only overriding for special occasions, but I don't see that capability yet.

[JerryBrightbill]

RE: On Error Goto 0

Blake

Actually, on error goto 0 does have an important useage. In some scripts , there may be a reason to turn off error trapping for a couple lines, and then turn it back on. It isn't used often, but does have a purpose.

As far as global error trapping, Alpha already has a version of that with the debugger. You can go into settings, preferences, and set the debugger to open on error. If that isn't what you need, it is very easy to create a global function to popup a custom error message. Then on the On error goto label, you can just return the result of the function.

Jerry

[Blake]

RE: On Error Goto 0

Actually, on error goto 0 does have an important useage. In some scripts , there may be a reason to turn off error trapping for a couple lines, and then turn it back on. It isn't used often, but does have a purpose.

Mais oui. But the code I've been looking at has all been turning it off right before the script/function/event exits--and that seemed unnecessary.

Was it possibly necessary in A4? I'm looking at a lot of code that was ported from A4 to A5 as quickly as possible.

As far as global error trapping, Alpha already has a version of that with the debugger. You can go into settings, preferences, and set the debugger to open on error.

Great tip!! Thanks!

If that isn't what you need, it is very easy to create a global function to popup a custom error message. Then on the On error goto label, you can just return the result of the function.

Cool, but how would you cause this global function to go? Say, for example, I had a UDF that unfroze the UI. How would I connect this to the error? I don't see a way to arbitrarily add code/events/functions to the "Script Errors" preference.

[JerryBrightbill]

RE: On Error Goto 0

Blake

I use the global function basically to save typing in conjunction with on error goto. Here is the "complex" code I have in the function.

FUNCTION Show_Error AS C ()
msg = error_text_get(error_code_get())+chr(10)+chr(13)+"Error occured at line "+str(error_line_number_get(),4,0)
ui_msg_box("Error", this.name()+" - "+msg)
END FUNCTION

In any script I want to trap errors, I still use the on error goto, but the code is much simpler

on error goto error_handler

' script code

end

error_handler:
show_error()
end

In one database, I also have another function that writes every error to a text file. If the file already exists, it just adds the current error with a time and date stamp and other info, like the logged on user name, to the existing file. If it doesn't exist (the preferred condition - meaning no existing errors), the file is created. If the user is claiming that errors are occuring, there is a saved record. For one user that had some very odd problems, I even trapped the last 20 keys pressed when an error occured. That solved a couple "user" errors.

Jerry

[Blake]

RE: On Error Goto 0

Yeah, that's the way we do our error handling, too.

It would be cool if you could replace the global handler, though, to default to calling your routine--then you wouldn't have to to put it in every single script.

By the way, I set up the "open debugger on error" option with disastrous results. The debugger opened--which was cool--but then, after I closed it, it tried running the same error again, and so it opened again. Neither "Break" nor "Skip" had any effect and since I couldn't correct the error from the debugger (which I guess might be possible if you could change a simple value) it basically shut me out of A5.

Worse, after killing A5 and trying to re-open the database, I got error messages in my Autoexec! So I had to kill A5 again. I had fortunately set the other debug preference (for Ctrl+Shift) on, so I could skip running it.

Phew!

[JerryBrightbill]

RE: On Error Goto 0

Blake

As you have found, some errors are very persistent. While that may make the debugger extremely annoying, I prefer that to just missing them or getting a single non-definitive error message. The debugger is doing exactly as it should, showing every error, even if it repeats. In some very serious errors, I have had to reboot the computer to clear memory. Usually just closing the program works, but not always.

The place where the debugger stops is a very big clue to the problem. If your autoexec also caused an error, then I would be very suspicious of something that exists both in the autoexec and in whatever script caused the first debugger problem.

One error that has caused exactly the problem you see is an error in a function called by the script. It could be a passed value that doesn't work, an expression that fails when values are added, of a file or table that can't open. When the script first hits the function, and there is a problem in the function, the debugger opens. Every time the function hits the same problem, the debugger reopens. Since the script hasn't "moved" to another line, it looks like the debugger is locked. The problem may just be one error causing another repeating problem in evaluating the function.

Anytime I get one of these repeating errors, I edit the script and add

debug(1)

a few lines before the problem occured. Then I will step one line at a time through the script, tracking various values as I go. If the problem is in a function, I run go to the interactive window and run the function as standalone and see how it behaves.

Debugging ain't fun, but at least the program gives some tools. Another place that can help track down errors is the trace window. If you open it, you will find some errors tracked there. I have been able to track down a few xdialog errors there that didn't show up anywhere else.

Jerry

[Blake]

RE: On Error Goto 0

As you have found, some errors are very persistent. While that may make the debugger extremely annoying, I prefer that to just missing them or getting a single non-definitive error message. The debugger is doing exactly as it should, showing every error, even if it repeats. In some very serious errors, I have had to reboot the computer to clear memory. Usually just closing the program works, but not always.

I'm wouldn't suggest that it should gloss over the error, but it should have an option to kill the process that spawned it. But I guess that'd be A5.

The place where the debugger stops is a very big clue to the problem. If your autoexec also caused an error, then I would be very suspicious of something that exists both in the autoexec and in whatever script caused the first debugger problem.

I don't have any trouble finding bugs. I can barely write them fast enough. (Heh.) I do wish one could set breakpoints without having to write code and that the debugger was actually part of the environment instead of a separate app.