# When and Why to use Console Logging

Why and in which way should I incorporate console logging into my small sized games? I use Java and C++.

With console logging I mean things like this:

Your question seems a little vague to me (mainly the how part, do you mean the concept or the coding?) but I'll try my best to answer it for you:

## Why

I know I use console logging in all my projects. For me, I mainly see it as a way for the end-user to report problems. An example could be, the game crashes for an unknown reason. So they come to help and support and say "My game crashes, here is the log:". The last line in the log is [APP] Loading: Resources. Well, now you have a great place to start helping the user.

I've found it also helpful to me when I'm developing. Sometimes I report important but non-crashing errors into the console. For example, if my game is loading extra entities that have no model data. Nothing will tell me this while running unless I get a [WARN]: Attempted to create empty model for entity #ENTITY-NAME#. This could be a performance problem if I'm trying to create and render a bunch of empty entities. With the console log, I can fix it easily.

Mainly console logging is just to do what the debugger can't. If your worried about performance, you can always just put the logging code into a macro (if in C++), and remove it in release builds. If you do keep it in for release builds, though, be careful as to what you put in it. In my projects, I don't put shader error dumps in release builds so users can't see what is in the shader code.

## How

What I'll do is give you the concept part. I'll explain how I usually do it, and you can adopt this method into your projects. Keep in mind I use C++, not Java. However, porting shouldn't be that hard. Because the adding of consoles into the project is language and class specific, I'll leave that up to you. I found it the first time by a quick Google.

What I do is create a class to handle the console. I always output the console logging to a file so the user (or me!) can review it after a game crash or unexpected closure. The handle to the file is managed within that class. It is a good idea to have this class available to all other classes. That way, you can always report a problem or status update. The way you do this depends on the structure of your application (you can make it global, or put it into another global class, or pass it to every object. It's up to you).

My console class always has these 5 functions:

• Log(string): Writes a line to the output file (usually private and only used by the other 4 functions).
• Print(string) or Info(string): Writes a regular status update or message.
• Warn(string): Writes an important but not fatal or erroneous message to the console. This message is prefixed by [WARN] or [WARNING].
• Error(string): Writes an error to the console. This message is prefixed by [ERROR].
• Fatal(string): Writes a fatal error to the console. This message is prefixed by [FATAL]. Also shows a message box with the error and stops the program.

I mentioned performance in the Why portion. Indeed, performance can come into play in release builds. There are so many ways to handle this. You could add an extra argument to the logging functions along the lines of bool release with a default of true. If it is false, the message will be ignored in release builds.

I hope that what I've written can help you decide if you need console logging and how to do it. Good luck!

• +1 and accepted, excellent comprehensive answer! This completely answered my question. Jul 13 '12 at 6:50

Console logging is used mainly to debug an application. It is always good to print out essential information, just in case something goes wrong you can have a first look to how things went. Information like library version, etc is always handy to have, especially if you are planning to run your application in different platforms.

What I usually do is set up different levels of debugging, each of them printing out different information. In your release level you can then set up a debugging level of 0, which would only print out essential information, as mentioned earlier. You can then prepare your code to print out a more detailed log when the debugging level is set to a higher number, which at the same time might affect your performance if you are also saving some debugging textures, etc....

In my games, I use the following macro's:

#define LOG_INFO(_msg, ...) { Log::Get().Message(Log::MessageType::eInfo, __FILE__, __LINE__, __FUNCTION__, _msg, __VA_ARGS__); }
#define LOG_WARNING(_msg, ...) { Log::Get().Message(Log::MessageType::eWarning, __FILE__, __LINE__, __FUNCTION__, _msg, __VA_ARGS__); }
#define LOG_ERROR(_msg, ...) { Log::Get().Message(Log::MessageType::eError, __FILE__, __LINE__, __FUNCTION__, _msg, __VA_ARGS__); }
#define LOG_FATAL(_msg, ...) { Log::Get().Message(Log::MessageType::eFatal, __FILE__, __LINE__, __FUNCTION__, _msg, __VA_ARGS__); }


This allows you to write this:

LOG_ERROR("Player is called '%s', which is a stupid name.", m_Name);


Which gives output like this:

[player.cpp:259] ERROR: Player is called 'SauerkrautUberAlles', which is a stupid name.


In any logging system, you will have to balance the following factors:

• Output - Do you want to output to screen? Console? File? Over network?
• Flexibility - Can you turn off logging for certain source files? Do you need that feature?
• Debugging - What info do you need to debug an error?
• Safety - Can a badly-formatted log message crash the game or worse, alter its state?

In my experience, a logging system needs to be fast above all else, including safety. In a game I worked, the log was only important when the game crashed. But when the game crashed, the log hadn't been written to the file yet! So to fix that, we opened the log file for every line, appended a line and closed it. This made sure that always got the very latest log message in the file before the crash.