Does anyone know how to trap/capture the error messages generated by the debugger?

What I want to do is have the error messages than occur at runtime suppressed, and written to a log file which can be reviewed later.

Ie. the program runs, if an error occurs, the error message gets written to a file, and the application re-starts (bypassing the task which generated the error).

I can totally suppress the debugger simply by replacing $RTP25 with my own code (which simply runs an ABORT ALL command forcing the application to re-start).

I don't think you'll be able to do that .. I don't think the source code for the Debugger has ever been published (which is what you'd need to have to do what you want).

I guess my puzzlement is why your code should be breaking to the debugger in the first place (except during testing / development). Of course, you could write your code in such a way that it could check for errors that would cause a break to the debugger and take approppriate action.

Don M.

Wasn't there a 3rd party debugger floating around for a time?

Curtail your amazement Don - even MY brilliant code occasionally gets to the debugger on rare occasions. In such cases I, inevitably, blame out Independent Testing Unit for faiing to spot a problem earlier!

The reason we shelled our debugger was to prevent a clued up user from re-enabling TCL by getting to @Environ.Set, as well as for purposes of audit and control. (Often a crash is "memory-related" and a lot of users simply don't bother to report they have a problem.)

Actually addressing Charles' question, yes it IS possible to shell the debugger and pick up the error code , and, as Warren points out, there have been various freeware replacements over the years. I downloaded the ones I use so long ago I can't even remember where I got the module from, but my RTP25 shell calls a routine called DEBUG.INFO, last compiled in 1993! This allows access to some of the parameters used by the debugger (e.g. program name & stack) and in conjunction with @Last.Error allows you to construct the same error message the real debugger would present. If you can't find this (or something better) in a library somewhere I can always pass on the object code, along with an RTP51 hack to read the relevant details from the REVERROR.000 file.

HTH,

Cameron

If someone can send me the DEBUG.INFO (or whatever) code, I'd appreciate it. - e-mail me : chuck_milner (at) yahoo.com

View this thread on the forum...