Making a Log File Class

[Luc The Perverse]

I have a class called "HistoryLog" which has a member variable of type
StreamWriter which is initialized in the constructor.

When I tested it on small outputs, nothing would write to the file, so I
looked in the documentation and found out the Close() function was
supposed to be called (or to use a "using" tag)

So I made a Dispose function and kept getting a FileNotOpen() error.
Searching google I found examples of people doing exactly what I was
doing, asking for help and being told there was basically no way to make
it work in this fashion.

Now I have 2 questions:

1. I am using a workaround, calling Flush() after every log write, and
never explicitly calling Close(). Is there any downside/danger to this
method?
2. Is there a better way to make a history log class that will take
care of ensuring the buffer gets emptied in it's dispose functional (or
some other way?)

My goal was to make a class which I could instantiate once, write to if
/ when needed and not have to worry about it again - a habit I got used
to in C++. If this is no longer feasible, I suppose I could get over
it. hehe


Thanks

 

[Ed Courtenay]

I have a class called "HistoryLog" which has a member variable of type
StreamWriter which is initialized in the constructor.

When I tested it on small outputs, nothing would write to the file, so I
looked in the documentation and found out the Close() function was
supposed to be called (or to use a "using" tag)

So I made a Dispose function and kept getting a FileNotOpen() error.
Searching google I found examples of people doing exactly what I was
doing, asking for help and being told there was basically no way to make
it work in this fashion.

Now I have 2 questions:

1. I am using a workaround, calling Flush() after every log write, and
never explicitly calling Close(). Is there any downside/danger to this
method?
2. Is there a better way to make a history log class that will take
care of ensuring the buffer gets emptied in it's dispose functional (or
some other way?)

My goal was to make a class which I could instantiate once, write to if
/ when needed and not have to worry about it again - a habit I got used
to in C++. If this is no longer feasible, I suppose I could get over
it. hehe


Thanks

Personally if I need to do any form of logging I use log4net - it saves
the hassle of re-inventing the wheel, plus it provides an very flexible
mechanism for targeting your logs (whether it be Console output,
rotating files or writing to the event log)

 

[Cubicle Snowman]

1. I am using a workaround, calling Flush() after every log write, and
never explicitly calling Close(). Is there any downside/danger to this
method?

Flush is a good option. I wouldn't recommend using Close() on your
streamwriter, since it also closes the underlying stream. (until your
destructor that is)
And for pretending to be thread-safe, it's advisable to contain your
write/flush section with lock().

2. Is there a better way to make a history log class that will take
care of ensuring the buffer gets emptied in it's dispose functional (or
some other way?)

My goal was to make a class which I could instantiate once, write to if
/ when needed and not have to worry about it again - a habit I got used
to in C++. If this is no longer feasible, I suppose I could get over
it. hehe

Just add Flush() to your Write()-segment and you dont have to worry about
it. To make it single instance, you could create a static HistoryLog inside
your program-class. Program.HistoryLog.Write("Debuggy text")

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,


If you want a full package for logging you better use log4net

Answers to your questions inline ...
--
Ignacio Machin
http://www.laceupsolutions.com
Mobile & warehouse Solutions.

Now I have 2 questions:

1. I am using a workaround, calling Flush() after every log write, and
never explicitly calling Close(). Is there any downside/danger to this
method?

You do not need to call Flush, I would open/close the log file each time you
write a log.

2. Is there a better way to make a history log class that will take care
of ensuring the buffer gets emptied in it's dispose functional (or some
other way?)

When you close the file everything is flushed.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Flush is a good option. I wouldn't recommend using Close() on your
streamwriter, since it also closes the underlying stream. (until your
destructor that is)
And for pretending to be thread-safe, it's advisable to contain your
write/flush section with lock().

Quite the opposite,I would close Close each time a log is written.

 

[Cubicle Snowman]

Quite the opposite,I would close Close each time a log is written.

Why? Completely possible that this is the right approach, but I would like
to hear the reasoning.
He wanted to use a single instance, so it seemed more logical to keep one
stream open instead of having to reopen it for each time the log is written.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,


Several reasons, like the possibility to delete the file to get a fresh log.
If you have the stream open always you have to close the program first.

I see the file the same way I see a DB connection or any other resource that
could be shared. use it when you need it and release it.

 

[Cubicle Snowman]

Hi,

Several reasons, like the possibility to delete the file to get a fresh log.
If you have the stream open always you have to close the program first.

I see the file the same way I see a DB connection or any other resource that
could be shared. use it when you need it and release it.

Good point.
I tend to keep my logfiles locked since I don't want some careless user to
accidentally manage to get rid of them. (daily recycle naturally as an option)
Different approaches for different uses. I was thinking more in the lines of
debugging log, but of course HistoryLog could likely indicate more seldom
usage.

 

[Luc The Perverse]

Why? Completely possible that this is the right approach, but I would like
to hear the reasoning.
He wanted to use a single instance, so it seemed more logical to keep one
stream open instead of having to reopen it for each time the log is written.

What I wanted was to create a class that I could create once and not
have to worry about closing it (or in any other way managing it) later.
I never really cared how the class worked internally as long as it got
my history events into a file for me.

I had never considered closing and re-opening the file every time.

I think that is what I will do.

I may be forced to move to a slightly more complicated setup if I intend
to allow multiple threads to use the log. But for now, this will work.

Thanks guys!

 

[Jonathan Wood]

I created a little LogFile class. You can read about it at http://www.blackbeltcoder.com/Articles/files/a-convenient-logfile-class.