When our application doesn't work the way we expect it to (e.g. throws exceptions etc.), I usually insert a lot of debug code at certain points in the application in order to get a better overview of what exactly is going on, what the values for certain objects are, to better trace where this error is triggered from. Then I send a new installer to the user(s) that are having the problem and if the problem is triggered again I look at the logs and see what they say.

But I don't want all this debug code to be in the production code, since this would create some really big debug files with information that is not always relevant.

The other problem is that our code base changes, and the next time, the same debug code might have to go in different parts of the application.


Is there a way to merge this debug code within the production code only when needed and have it appear at the correct points within the application?

Can it be done with a version control system like git so that all would be needed is a git merge?

P.S. The application I'm talking about now is .NET, written in C#.


For the VCS side:

  1. In case of Git you have to have two separate branches for clean and debug versions. Ordinary work happens in master, debugging - in debug branch (or bugfix branch, branched from debug) with added debug information.

  2. During lifecycle you permanently merge changes from master to debug, thus - have two versions, which differ only in debug information amount. After bug-hunting you backmerge (from debug to master) only relevant part of changes from branch.

BTW: Mercurial with MQ require less frictions around branching-merging and use only one mainline branch, while allow to use insertions of debug code


IMHO the best way is prevention, by logging all the necessary information within your exception messages. In the ideal case, this - together with the regular log messages - would be enough for you to reproduce the bug in your dev environment. But even in the less-than-ideal case, this should help you focus your investigation better, needing less extra debug logs to determine the exact root cause.

In the latter case, as others too suggested, you can minimize the disruption and performance penalty caused by superfluous log messages by setting log message levels carefully, and applying the appropriate log level threshold in production. I am not familiar with C# logging frameworks but in Java, all mainstream logging frameworks allow this, so I am pretty sure you can find similar solutions in the .Net world too.

  • +1 An exception can contain much information and is treated as a single, atomic entity by frameworks. – user1249 Nov 23 '11 at 12:25

You could have a series of message via debug(), info(), trace() level of logging. Something like nlog will allow you to do that. During production, you can set the level of logging and anything under what you want will be discarded.

Edit: I would suggest wrapping nlog under a class of your own and use that class. That way, if you decide to change logger, just one class needs to change.


Have you looked into a logging framework like log4net (there are others too, but this seems to be the most popular for .NET)? I've used the Java equivalent, Log4J and it has the ability to log messages at different levels, such as Info, Warn, Error, Debug, Fatal. You can change the application's logging level through configuration rather then building it in. That way, you can normally run your application in production at the "Fatal" log-level, but on your workstation, run logging at "Warn" or "Debug" and no recompiling is necessary!

The only hard part is figuring out what level a logging message should be.


If you are only worried that the debug code will create big debug files you can still have it in production but disabled ( maybe with a global flag )

so when you want the user to turn it on have him change a config file or pass an argument to the executable.

Note: I am assuming you already have some debug code, if not I think Sardathrion's answer is the best.

  • 2
    conditional pieces of debug-code is bad-style of coding – Lazy Badger Nov 23 '11 at 12:09
  • @LazyBadger nlog does the same thing in the background. When you log a debug or info message a condition is applied as to whether it will be actually logged or ignored. Why is it a bad style of coding? – Thanos Papathanasiou Nov 23 '11 at 12:54
  • 2
    @LazyBadger: Depends on how you do it. There is of course the option of conditional compilation... Also, you can have the debug code execute unconditionally, and have the logger decide to send it to the bitbucket or to an actual log depending on some flag (or the existence of a file, or ...) – Marjan Venema Nov 23 '11 at 13:29
  • in any case we get at least dirty code. Consider it, if you want, as IMNSHO (~30 years in-game matters?!) – Lazy Badger Nov 23 '11 at 13:33
  • 3
    @LazyBadger: No you don't. You get something that is easy to debug at a distance. Incredibly valuable when your clients are halfway around the world and security won't let you access their computers, nor will your clients appreciate getting several debug builds to install so an issue can be tracked down. 25+ years in Software development from mainframes to pc's both in-house, shrink wrap, and web count for any value? :-) – Marjan Venema Nov 23 '11 at 13:49

I would advise against having production versions with debugging built-in, and others without. Build your debugging into the production code and either:

  • choose a way of turning it on and off at start-up from the various suggestions above.
  • make it turn on on-demand.

You could perhaps do the latter by using property grids and reflection to inspect your objects at run time, activated by a secret hot-key.

If you're worried about spewing out large debug files, you could write it all to memory, and only output it to file or screen if you need to (e.g. at user's command, on Exception, or if a switch is on for that particular feature etc...)

A final throw in about debugging is that you can often save a lot of time by simply asserting whether conditions are true or false inside your methods and properties, instead of writing to a debug file which you'll have to physically read to determine what the condition was.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.