Stream Style

Top  Previous  Next

Basic printf-style debug logging statements look like this:

debugout << "This is a debugging message.";

debugout << "There are " << count << " items.";

 

But you can also specify more information in your stream (aka JrDebugStream) invocations, which add useful information to your debugging statements.  To get the most out of JrDebugLogger you should learn to specify this additional information.

 

Some examples of providing additional information:

// add message type:

debugout(JrdWarning) << "This is a debugging message.");

// add message type and severity level:

debugout(JrdWarning,100) << "This is a debugging message.";

// add message type, subtypestring, current activity, and severity level:

debugout(JrdError,"minor","testing",100) << "This is a debugging message.";

 

This extra information is mainly just to help you identify the messages - and shows up as different columns in the Debug Monitor Viewer.  However some of these extra fields can be used to control logging behavior:

You can set filters on severity levels to indicate that certain severity levels should be ignored; you can set alarms to trigger on messages with severity levels above some value.

 


Prototypes for stream configuration:

 

operator()(const JrdType inmtype , const int inseverity=JrDebugDefaultLevel);
operator()(const JrdType inmtype , const char *indmsubtypestr, const char *inactivity="", const int inseverity=JrDebugDefaultLevel);

 


Message types are specified with the JrdType enum:

 

enum JrdType { JrdMessage, JrdWarning, JrdError, JrdAlarm, JrdNote , JrdTest , JrdCustom , JrdAssertPass, JrdAssertFail, JrdException };

 

Special handling of Message Types:

The following message types are special and should not be specified manually: JrdAssertPass, JrdAssertFail, and JrdException.
If the JrdCustom type is specified, the text from the dmsubtypestr is used alone for the Type field; otherwise the Type field will be messagetype.subtype (ie "Error.minor".
Any message sent of type JrdAlarm will trigger a popup windows messagebox (or an output to stdout if compiled on *nix), to alert the user to the event even if a debug monitor is not engaged.