Best way to trap a runtimeerror in a a5 application?

[B.B.Bongers]

Hi Guys,

We have a multiuser application build in A5.
The a5 application crashes sometimes without any errors.
Does alpha provide a central errorlog wih an errorstack in runtime?
This could be usefull to tracking an error.

Kind regards,

Brendo

[Finian Lennon]

Re: Best way to trap a runtimeerror in a a5 application?

There are several basic tools

On Error GoTo
err = Error.Code_get()
msg_text = error_text_get(err)

Are all well discussed in the online help.

At runtime, when an app dies without throwing a error, running the app with the full-version, and inserting a debug(1) statement can also force an error message to be thrown.

A good read of the help should show you how to address your particular situation.

[B.B.Bongers]

Re: Best way to trap a runtimeerror in a a5 application?

Thanks Finain.
The errors occure on more than one client(runtime version) and the regular users are suppposed to be able only running the runtime version.
Only the developers/Administrators have access to the full version.

The errors showing up suddenly and not at a particular event.
Reproducing the error with the full version will be a little bit hard.

[Finian Lennon]

Re: Best way to trap a runtimeerror in a a5 application?

Assuming that you can narrow it down to certain scripts you could insert the code at the start of every script

On error goto error_handler

error_handler:
err_msg = error_text_get(error_code_get())
line = error_line_number_get()
script = error_script_get()
ui_msg_box("Error", err_msg + " Error occurred at line " + alltrim(str(line, 4, 0)) + "in script: " + script)

The above is lifted directly from the help which you would do well to study.

It's sometimes useful to create a function that captures the errors and writes them to a table while allowing the script(s) to continue to run. I do this in eclaims where a claim is subjected to many validation tests any of which will prevent the claim from being submitted. I write all the errors to the table and then generate a report at the end so the user can go back and make multiple fixes before re-submitting.

[B.B.Bongers]

Re: Best way to trap a runtimeerror in a a5 application?

Thanks Finian

I am aware of this "try catch" construct..vb/asp also uses the same kind of method:) We are already using this method in the application.

[Finian Lennon]

Re: Best way to trap a runtimeerror in a a5 application?

As you have probably discovered, code errors are sometimes not "reported" at run time. In those few instances, a script just fails and there is no indication of the nature or location of the error. This is, obviously, not a good position to be in when there is no full version of the program available to run a debug on the offending code.

[Al Buchholz]

Re: Best way to trap a runtimeerror in a a5 application?

Have you tried the option of xbasic_trace_start() which will write the results to a file. I've used that with a unique name for each user and been able to trace some relatively strange circumstances.....

or xbasic_error_log() - internal only use.....

[B.B.Bongers]

Re: Best way to trap a runtimeerror in a a5 application?

Have you tried the option of xbasic_trace_start() which will write the results to a file. I've used that with a unique name for each user and been able to trace some relatively strange circumstances.....

or xbasic_error_log() - internal only use.....

Thanks, I will try to implement
xbasic_trace_start() with a username + timestamp as log filename.