2

Fatal

For unrecoverable errors that result in terminating the program. For example, report a fatal trace event before a call to assert(), exit(), or abort().

3

Error

For recoverable errors, such as exceptions that are caught and handled, dropped connections that can be reestablished, and recoverable database errors. Report an error trace event before throwing an exception. Do not generate an error trace event for error conditions reported (by your code) as function return values or for exceptions reporting expected conditions, such as end-of-file, time-out, and illegal-usage.

4

Warning

For advance notice of impending problems. Report a warning trace event, for example, when the program is nearing resource or performance limits.

5

Informational

For documenting program flow. For example, Connected to Client and Startup Complete are representative informational statements.

6

Test

For testing information, such as the state of objects, needed to document that your software performed successfully.

7

Debug

For low-level information used in code debugging or unit testing, such as local variables, loop variables, and branching logic. If error conditions are detected only under debug builds, report them as debug trace events, not as fatal or error events.

8

Entry

For documenting the call order of functions. When a function is called, the statement generates the output message Entry. When the function returns, an Exit message is generated. These messages are generated automatically when a function is declared to be traceable.