Over the past seven or eight years I have developed a list of five key interview questions for recruiting staff to software development teams. These five questions have come to stand out as being highly indicative of the candidate’s aptitude for approaching software in [what is now called] a “DevOps” manner, namely, seeing software as the running, evolving system in the Production environment.
[This is a very old article I wrote back in 2002 when I worked for a company which built MRI scanners and was subsequently bought by Oxford Instruments. The driver for this was “…Until Delphi acquires native functions equivalent to the C [__LINE__ and __FILE__] macros, … the need for this Assert-based framework … will remain” The need to trace errors to a specific class and line number, especially in production code, has only become stronger since then.]
This note describes a simple but flexible error-reporting and tracing framework for Delphi 4 and above based on Assert, which provides the unit name and line number at which errors were trapped and traces made.
Under the Delphi Language there is no simple way of replicating the C/C’++ macros —FILE— and _LINE_ to obtain the unit name and line number of memory address at runtime. However, in his paper “Non-Obvious Debugging Techniques” Brian Long points out that the Delphi compiler provides both unit name and line number during a call to Assert, and describes how assertions can be exploited to provide detailed execution tracing.
The framework described here extends this idea to allow flexibility in the processing of assertions. Assertion processing can be switched on and off at runtime; arbitrary filtering can be applied to any assertion; and both execution tracing and ‘standard’ assertion behaviour (i.e. raising an exception) can be effected. Assertions can therefore be left enabled in production code, at the expense of a slightly larger binary executable.