BlackBox has different approach in development strategy:
The BlackBox debugger is a cross between a "post-mortem" debugger and a "run-time" debugger. It is invoked after a command has trapped (post-mortem), but it doesn't cause a termination of the BlackBox environment (run-time). Some features, such as the Info->View State command, which makes it possible to follow data structures starting from a selected view, are usually associated with run-time debuggers only.
It is typical for object-oriented programs that their control flows can become extremely convoluted and hard to follow. Thus following a program statement for statement (single step), by message sends, or by procedure calls in practice turns out to be unpractical for debugging large systems. Instead, BlackBox uses a more effective debugging strategy:
Let errors become manifest as soon as possible.
Instead of waiting for some error to occur, and then trying to find one's way backward to the cause of the error, it was attempted to flag errors as closely to their cause as possible. This is the only way to truly save debugging time. The language implementation follows the same strategy, by checking index overflows when accessing arrays, by checking NIL accesses when dereferencing a pointer, etc. In addition to these built-in checks, Component Pascal provides the standard procedure ASSERT, which allows to test for an arbitrary condition. If the condition is violated, a trap window is opened. Procedures of the BlackBox Component Framework consequently use assertions e.g. at the beginning of a procedure to check whether its input is valid. This prevents that a procedure with illegal input may perform any damage to the rest of the system.
This defensive programming strategy has proven itself again and again during the development of BlackBox, and is strongly recommended for serious development work.
Refer to User Manual of Dev Subsystem from help system, section 5.
Trap window looks like this:
