About: Tracing
01 Programs - especially those working in the background - sooner or later need to tell what they are doing. Not only for one to be able to monitor any activity, but mostly for debugging to be able to recreate what happened (what went wrong).
02 This process has several names. In the context of Semys, the name is 'trace'.
03 Because tracing is such a common function, there exist numerous components, libraries and systems that provide this functionality and even more specifications on how to store such output.
Both Semys Lib and Semys Arch provide their own (extensible) tracing facilities. See corresponding documentation for more.
04 The focus of this chapter lies more on the creation of traces, rather than its storage format.
05 Nearly every tracing facility offers the possibility to classify the output - typically in categories like 'Error', 'Warning', 'Info' and sometimes 'Debug'.
A further feature of this classification also often is the possibility to filter certain categories, not storing those being filtered.
06 Semys Arch, where a classification of traces can be done, does not support filtering certain categories. (The extension mechanism would allow a provided listener to do so, though).
07 This filter mechanism often is used to ignore (nearly) all output in release environments where traces should not use up resources. "The system is expected to run well anyway - why keep traces?"
08 The problem arises when the system does not run well and produced an error. The error (bug) can not be traced back to its original cause because of missing traces.
So, the filter are removed and the system is re-run in the hope that the bug will reappear (reproducable) with the proper traces - A method that is not always possible nor effective (as the bug does not reappear).
09 Based on the experience of the author, even a complex system does not need to filter its detailed traces - nor does it need such detailed ('Debug') traces at all, which is why Semys Arch knows only the three trace levels 'Error', 'Warning' and 'Info'.
10 Placing trace outputs (and their content) should be based on common sense.
The invokation of a timeout handler every 50 msec does not need to be traced, but a request that had not received an expected response after 5 seconds should be noted.
The call of a helper function does not need to be traced, but if it returned an error, the corresponding trace should be easy to locate in the source.
11

As noted above, tracing is a topic that is discussed very often - and my few blocks here probably are no news. What I want to make clear is that it is possible to work without any detailed trace categories and filter - at least in my opinion.
The Semys Arch tracing facilities allow anyone that misses certain features to extend them by connecting his/her favourite trace library.

Goto: Main Page; This page is part of the Semys software documentation. See About: Documentation for details.