Making a Log File Class

  • Thread starter Thread starter Luc The Perverse
  • Start date Start date
L

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
 
Luc said:
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
Click to expand...

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)
 
Luc The Perverse said:
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?
Click to expand...

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 ;)
Click to expand...

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")
 
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?
Click to expand...

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?)
Click to expand...

When you close the file everything is flushed.
 
Hi,



Cubicle Snowman said:
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().
Click to expand...

Quite the opposite,I would close Close each time a log is written.
 
Ignacio Machin ( .NET/ C# MVP ) said:
Quite the opposite,I would close Close each time a log is written.
Click to expand...

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.
 
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.
 
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.
Click to expand...

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.
 
Cubicle said:
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.
Click to expand...

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!
 
Back
Top