Nested Try/Excepts to Traceback Errors

[6volt]

I thought I was doing this properly over the years but just realized I'm doing it wrong when I was losing an Out of Bounds OS exception.

My general approach when I write code is to encapsulate every routine with a T/E and append the E.messages so that I get a Traceback list of the calling routines that lead to the exception.

I need to do this because I have a lot of little low-level "widget" routines that if they fail, it could be from any part of the code.

NOTE: Yes, I know about the IDE Debugger but for the way this code is run by many machines on a network, using the IDE is not as easy at it would seem.

I have found the following to be true when nested T/E are involved, especially through the tree of routines called:

1) I have to RAISE an error in the Except block, otherwise the Except is executed and the program continues,
2) When I Create my Error to be Raised, the message parameter is appended with the class and E.Message of the exception that occurred. This could be an exception that I Raise in my code or an OS exception.
3) Each T/E then appends information relevant to the location of the T/E, at a minimum, it will be the name of the routine it is in. If I get fancy, it will also include the parameter values and other internal information.
4) Every T/E in the program is done like this except for the Top Level T/E.
5) The Top Level T/E has the ShowMessage with the final concatenated error message.

At least, this is what I think should work at this point. My previous version of this assumed that the OS exception message in E.message was available when the Top Level T/E was reached. What I did not realize was that when I Raised my created error, that message overwrote the OS message. Therefore SOLUTION was to always start with appending the E.message first to my newly created exception. That should preserve the OS exception message.
________________________________

If there is a better way to do this, I'd like to hear about it. BTW, I'm stuck in Delphi 7 land. My partner started to migrate to the newer versions and the IDE was a nightmare. With lots of difficulty involved and then the MS .NET arriving, he decided to jump ship to .NET so that was the end of Delphi here. I've been working on this project since D7 was the current version and simply have stayed with it.

Thanks in advance,
Tom

 

[Griffyn]

I have a few thoughts.

Designing your applications around the concept of alerting the user whenever an error occurs is a bad idea. Every effort should be made to handle all possible errors gracefully (eg. data validation, communication interruptions, etc.) so that the user is presented with both information on what is wrong and how to fix it (eg. "The date you entered is invalid. Please ensure you enter the date in this format m-d-yyyy"), or have the program handle things automatically, eg. retry if appropriate. An alert message with what is likely to be meaningless gibberish to your user should always be avoided.

It sounds like your applications are not being properly tested in the IDE, which is where it really shines. Being able to step through the code one line at a time, and inspect the values of variables and return values of functions is really valuable.

Traceback data can still be collected via logging (to a text file, or database table), and will provide you with more information than nested exceptions will, because you will also log information from any or all the processes in the lead up to the exception when it occurs (which is also logged). Logging performed through a common function can also be easily disabled throughout a project when it's time for deployment or the project is stable. And - logging also provides comments throughout the code.

 

[6volt]

Griffyn,

We think alike!

First, at this time, the code is Research Code and only I run it. It will advance to Research Code that "other people" run, and then finally a Production Code. Obviously, all the things you said apply to this, especially as it progresses to Production Code.

Part of the Traceback is to provide the require correction information.

In a few cases, I tell the User to "Close old Excel process and press ENTER" and the code resumes.

In most cases, the input is like a Finite Element Program in that there are massive amounts of input required and it is all done via a .INI file. Not a GUI! So if the .INI file needs to be changed, the execution is terminated. So this is Old School right now. Obviously, the Production Code will require a GUI to be constructed.

I have used the IDE debugger in the past, but now, the program runs on "workstations" supported by a "data/source server." The program itself does all the loading of the executables and required data onto the workstation temp area. To run this in the IDE debugger, its a matter of moving the information from the workstation to a dummy area in the "code development PC" and constructing a long command line input in the IDE. It can be done, but I am so familiar with the code, just a few hints and I can usually find the bug.

The main thing I'm looking for is when an OS Exception occurs, it would be nice to have the Line Number but that is not available with Delphi - big loss in my book. So I at least want to know, 1) what routine produced the exception, and 2) what what series of calls lead to that particular running of the routine.
_________________________________________

It turns out that I needed an IF statement in the EXCEPT block to differentiate between an OS Exception and a User Input Error that I manage. THe EXCEPT logic is as follows:

1) let emsg hold my E.message information
2) If OS Except, append E.Classname and E.Message to emsg and RAISE,
3) Append My Traceback Location Information Message to emsg and RAISE

Note that when I RAISE a User Input Error, it has a Class of "My"Error and I build the E.Message where I RAISE that Exception in the TRY area.

Thanks
Tom