Having just expressed August's final proof back to Bill Anderson-lacking this page, of course-I have only to write this column, then it's on to October. Instead of writing an August issue overview, I'll describe a small useful workaround for failure handling with Think Pascal 4 (announced August 6th, and now shipping).
Because of all this, life was difficult when debugging anything with Think Pascal 3 that involved failure handling. The most useful technique for debugging failures-setting a stop sign at the beginning of the Failure procedure, so that you can see the context of the error before MacApp's failure handling cuts back the stack and displays the error dialog-caused Think Pascal 3 to crash when a failure occurred. I find it convenient to write code that uses failure handling even for recovery from soft (non-catastrophic) errors, so this was a real problem for me.
With the new release, Think Pascal 4 provides a couple of replacements for the MacApp failure library that you can use when debugging in the Think environment-one for use with the MacApp debugger, one for without. These libraries call a special trap that causes the Think Pascal debugging environment to do the cleanup it needs to for each routine that was on the stack at the time of a failure.
In my experience, with these special failure libraries, Think Pascal 4 is now almost 100% reliable. Most mysterious crashes of the Think environment eventually turn out to be my own runaway code trashing something that's none of its business. (Oh, for a protected memory space!) There are only two limitations: (1) you have to compile your entire application, including MacApp, with the Think debugging option on, because the special failure library isn't smart about not calling the Think cleanup code if a routine on the stack wasn't compiled with the Think debugging option; and (2) for some reason, which I hope Symantec technical support can eventually explain, a failure during application initialization(IMyApplication) still crashes Think Pascal, if you're using the special failure libraries.
The first limitation isn't serious unless your code runs too slowly when the entire application is compiled with Think debugging on. And it's safe to compile units that won't fail, and that don't call any routines which could fail, without Think debugging.
The second limitation seems to be the last remaining bit of Think Pascal's former unreliability that developers have lived with for so long. If your application does nothing complex during initialization, and your code doesn't have any bugs, you may not encounter the problem. I have an application that looks for devices during IMyApplication, and that uses failure handling as a way to gracefully handle their absence; if you do something like this, you'll be sure to repeatedly encounter the hard crash.
I've come up with a simple workaround. It's kind of odd, but it seems to circumvent the problem, and not cause any new ones, either.
Do be sure to contain these changes within {$IFC} directives, so that it's easy to build your standalone application without them. This workaround is a hack that's just intended for using during debugging; you don't want it in your final code! n
