Stack traces: Difference between revisions
→{{header|Fortran}}
Line 730:
=={{header|Fortran}}==
Fortran provides nothing of the sort as a language feature. A given compiler may (possibly via an option) record information in the code file that when a fatal error such as divide-by-zero is caught, allows the error message to name the routine in which the error occurred, possibly identifying the source line and perhaps even the sequence of routines that were invoked to get there. Otherwise, a routine has no information whereby it might identify its caller - or for that matter, itself. Some compilers might make available special routines, but, there is no such requirement in the standard. Outside of Fortran's lack of standardised access, some systems such as TaskInfo on Windows can show a task's current call stack (updated each time TaskInfo re-samples, say every four seconds), possibly including the names of the called routines. Watching this being updated as the task runs a lengthy computation gives hints that otherwise could be provided via execution profiling and a lot more effort.
Otherwise, it is up to the programmer. For instance, on entry to ''every'' routine, <code>CALL SUBIN("''name''")</code> and on exit, ''without fail'', <code>CALL SUBOUT("''name''")</code> which routines maintain a ... stack of names, and further can count invocations, though perhaps not for heavily-used routines - trials suggest that around ten million SUBIN calls consume about a second of cpu time. Add to this the judicious use of a routine <code>CALL STATE("''activity description''")</code> similarly using a stack (the stack pointer being maintained by SUBIN/SUBOUT) not only provides interesting documentation in the source but also, should there be a disaster, <code>CALL CROAK("''dismayed message''")</code> can be used to end a run, routine CROAK of course displaying the current stack with at each level the declared activity message before the final STOP. A similar routine could be invoked to display the current stack state without a STOP as some sort of status report. With this protocol in place, the routine to present trace output can name its caller (and, the caller of that) to provide some context for the bewildering output.
Here for example is a run of such a programme, called Gnash (for New Zealand's national collection of half-hourly electricity data) that accepts certain commands and in particular a command "croak". A log of input and output is maintained, echoing what appears on the screen. Thus, the programme requests the next input after prompting "Gnash:" and that input is the command "croak" followed by some text...
Line 743:
...from Gnash Gnash gnashing
Omitted exit from level 3:XeqACard
Omitted exit from level 2:Attack
</pre>
So, Gnash has invoked ATTACK to deal with input commands, as if cards are being read. ATTACK states that it is dealing with some input (possibly from a script file but in this case the keyboard), and invokes XeqACard to do so. It states that it is confronting some text, then invokes the appropriate command handler - which invokes CROAK, which unwinds the stack. Its final act is <code>STOP "I STOP now. Farewell..." !Whatever pit I was in, I'm gone.</code> which of course is not written to the log file and unless you're using a DOS-style session, the window will be closed before you can read it.
| |||