Jump to content
  • Advertisement
Sign in to follow this  
3dmodelerguy

what would you like to see in a error logging system?

This topic is 4833 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Me and a friend i know online are are a game enigne. I have just finished creating a test my logging system. right now this is what you can do in it after creating the CLogManager Object (NMessage::CLogManager log;): create any log file you want by giving it a name and file location (log.CreateLog( "error", "../../../Product/W32/Logs/error Logs.log" );) log and custom message by giving the name of the log you want to log it to and the message (log.LogCustomMessage( "error", "custom message test error" );) log and defined message by giving name of log you want to log to and messages id (log.LogDefinedMessage( "audio", 4 );) want else would you want to see in a logger that would be helpful to use for the game or debugging

Share this post


Link to post
Share on other sites
Advertisement
Well think there should only be 1 log file, typically ~app name~.log, but really this whole concept could be put together with errorand exception handling, IMO.

U could have 1 class that does all this.

ace

Share this post


Link to post
Share on other sites
well i am using more that 1 log file becuase it help sort out where something it happening, its really more of a organizational thing in having more then 1 log file.

Share this post


Link to post
Share on other sites
Here was the requirements list for the last logging system I had to do:

Easy for devs to use.
Fine-grained control over what is (and is not) logged.
Output to any or all of logfile, stdout, OutputDebugString (for windows), in-memory circular buffer (useful for debugging).
Live changing of logging options.
Low overhead in the filtered case.
Non-blocking (as much as reasonably possible).
The ability to compile out the logging code entirely (like asserts).
The ability to create a new log file every so many hours and/or megabytes of log data.

Share this post


Link to post
Share on other sites
Quote:
Original post by ace_lovegrove
Well think there should only be 1 log file, typically ~app name~.log, but really this whole concept could be put together with errorand exception handling, IMO.
flexible design is good. Restricting yourself to one logfile doesn't add any real benefit, and allowing multiple log files doesn't have any real cost. If you later want to add another log file then you don't have to change existing code.

Share this post


Link to post
Share on other sites
Hey,

I was going to say something about you guys saying that you were a game engine... but that would be lame. So instead, I'll give my 2 cents.

* Global logfile
Have many logfiles if you want, but log every single message to a given .log file, at least in debug mode or when someone switches it on.

* Priorities
My previous logging class incorporates a bunch of priorities, where you could say Write (Priority::CriticalError) and it would make sure that it was logged. This was so that you could bung a whole heap of trace statements into the code and follow them easily.

* Console hookin
I know it's not so related, but in my previous projects this helped a lot. Being able to set up the log to write to memory and not a file was really really handy. I could send infos to the console and I wouldn't have to exit the fullscreen app to find out what was said. Invaluable.

I never did get around to being able to dynamically filter what level of error messages were displayed in the console though.

* Multiple targets
Sort of self explanitory. Writing to multiple logs [at once] is very handy, especially if you're wanting to be able to sync events across all logs.

* XML / HTML / Whatever output
Text gets old, fast. In my ideal logging system, each high priority event would have an icon to the left of it in the output, like a little exclamation symbol when there's an error. Multiple colours are also handy. Maybe straight HTML with some javascript parser magic or something. This is a dream feature...

* Dynamic filtering of output
Another dream feature, relies on DHTML or whatnot, but it'd still be cool, wouldn't it?

* Autoarchival of old logs
You wouldn't want to lose your logs, so make sure you back them up. It's very handy to be able to tell when an issue was introducted.

Of course, put these things together and you'll be _my_ hero.

CJM

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!