At this point, you should probably look into a logging library. Most of them allow you to customize the formatting of your logs without changing the code itself, and you can even add different formats (including colors) for different log levels or depending on which class or method the log came from.
The one I use is NLog, but you can probably find others by searching online.
Also, to provide more context as to what I am actually doing right now with the code on screen:
I used NLog for a cool project at work and I really became a fan of its Factory/Configuration model for new loggers. I am implementing a simillar pattern into my project which will allow users to easily create a custom configuration and pass it to the factory for that object. The configuration will then be applied to the object during instantiation by the factory and the factory will return an instantiated object to the calling method.
So... I mean, lots of people use loggers, like NLog. If your shop somehow doesn't have a logger chosen, that's my preference. But generally, you should ask your dev manager what your logging strategy is.
There's a lot of good advice in these answers, but I think something that we often forget is that there's more than just catch(Exception ex)
. There's times where I may want to do something like:
catch(HttpRequestException hre) { //Log to discover who broke what server } catch(NullReferenceException nre) { //Log to discover who left a required param null } catch(Exception ex) { //Okay, what the hell is going on? }
As you can see, SOMETIMES the context of the exception matters. And sometimes just logging the exception WITHOUT the other data (i.e. maybe if I'm making a web request and that throws, I want to know what sort of request data I sent) can be important.
Similar to the other suggestion, my company uses nlog. The best thing about these logging frameworks is you can set up almost any kind of target: console, file, database, event log, email, etc...And you can do this all in your config file. You just have to write to a single logger, and based on your configuration rules, the logged message will get routed to the appropriate targets and written.
My default configuration is a ColoredConsole and File targets; everything I print to the console gets printed to a log file that I can review, along with some extra information like call sites and such.
Definitely check out logging frameworks; it's something that is important to get right (you don't want to crash your app because of logging statements) and it's not worth re-inventing the wheel over.
This. Though we prefer Nlog, both it and log4net are very comparable frameworks. There are some things you just don't want to reinvent yourself, because it seems initially simple but will invariably trip you up if you try - anything to do with Dates and time, for example. Logging is another.
It looks like you are doing logging, you should consider replacing this custom built solution with something like nLog. http://nlog-project.org/
It's super easy to write to a file and also to back up that file to a zip file, also write to the event log, a database, the network emails, rss, messageboxes, windows forms, message queues, debuggers, consoles, cats, dogs, babies, whatever....
For instance the file target has automatic archiving that allows you to archive when files get too big, after a certain amount of time and I'm sure other options as well. https://github.com/nlog/nlog/wiki/File-target