Does this look good?

[cj]

Public Class MyStringLogger
Private Shared m_loglock As New Object

Public Shared Sub Write(ByVal str As String)
SyncLock (m_loglock)
Dim sw As New System.io.StreamWriter("c:\validate.log",
True)
sw.WriteLine(str)
sw.Close()
End SyncLock
End Sub
End Class

I have a class SessionClass in this program that gets instigated in it's
own thread when the program is running. Many of these instances might
be running at the same time each handling a TCP/IP communication
session. From within SessionClass I use:
MyStringLogger.Write("something worthy of logging here") to add a line
to my log file.

It works but does anyone see any potential problems? Comments welcome.

 

[Cor Ligthert [MVP]]

cj,

A potential problem I can see is that if your writing process to drive is
stucked for whatever reason, all the threads should wait (and do because
they are synclocked) until that writing is done. If that can give errors in
your application (and I thought that it was about scanning TCP ports)
because you miss something than you are in trouble.

I would use a Queue which is filled from the top (or visa versa) by the
threads. And synclocked when filling. The same synclock is used to get a
string from bottom and than the synclock is ended. The string is written
(not synclocked) to disk independent from the other processes.

http://msdn2.microsoft.com/en-us/library/system.collections.queue.aspx

You need a timer to see everytime if there is something in your queue.

Be aware at the end of your program to empty the queue you have than to do
this as well.

I hope this helps,

Cor

 

[Stephany Young]

Cor's comment about getting 'stuck' on the actual physical write to disk is
valid, however I would consider it to be low risk.

In my opinion, a more pressing potential problem would be the inability to
open the file for appending. This could happen if another process has the
file locked.

When I use this technique I work on the principle that if the operation
suceeds then well and and good but if it doesn't then I'm not going to lose
any sleep over it. To achieve this I code, within the Shared Sub:

SyncLock (m_loglock)
Dim sw As System.IO.StreamWriter = Nothing
Try
sw = New System.I.StreamWriter("c:\validate.log", True)
sw.Writeline(str)
sw.Flush()
Catch
Finally
If sw IsNot Nothing Then sw.Close()
End Try
End SyncLock

This ensures that you don't get an exception on the Close if the open
failed. The Flush forces the buffer to be written to disk and can avoid
lines been written out of sequence when the Sub is called from differenrt
threads. I don't know how this happens but I have observed it occassionally.

I also tend to prepend the the log message with a timestamp down to
millisecond level, thus giving some rudimentary performance monitoring
information:

sw.Writeline("{0:HH:mm:ss.fff} {1}", DateTime.Now, str)

Note that the timestamp here is the time that the Writeline operation occurs
rather than the time of 'event' that caused the call to the Sub.

I suggest having a play with it, observing the results and tweaking it to
your own needs.

 

[TerryFei]

Hi Cj,
Welcome to MSDN Newsgroup!

I agree with Stephany's point here. You should call flush method to clear
the buffers for the file and cause all buffered data to be written to the
file. This will force any data remaining in the file buffer to be written
to the file. It helps protect you from some potential problems.

Thanks and have a nice day!

Best Regards,

Terry Fei [MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security

--------------------

 

[Jay B. Harlow [MVP - Outlook]]

Stephany,
| Catch
| Finally
Be mindful of losing exceptions with empty Catch blocks. I would recommend:

| SyncLock (m_loglock)
| Dim sw As System.IO.StreamWriter = Nothing
| Try
| sw = New System.I.StreamWriter("c:\validate.log", True)
| sw.Writeline(str)
| sw.Flush()
| Finally
| If sw IsNot Nothing Then sw.Close()
| End Try
| End SyncLock

The IsNot suggests VS 2005, I would recommend the Using statement instead,
see my other post.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Cor's comment about getting 'stuck' on the actual physical write to disk
is
| valid, however I would consider it to be low risk.
|
| In my opinion, a more pressing potential problem would be the inability to
| open the file for appending. This could happen if another process has the
| file locked.
|
| When I use this technique I work on the principle that if the operation
| suceeds then well and and good but if it doesn't then I'm not going to
lose
| any sleep over it. To achieve this I code, within the Shared Sub:
|
| SyncLock (m_loglock)
| Dim sw As System.IO.StreamWriter = Nothing
| Try
| sw = New System.I.StreamWriter("c:\validate.log", True)
| sw.Writeline(str)
| sw.Flush()
| Catch
| Finally
| If sw IsNot Nothing Then sw.Close()
| End Try
| End SyncLock
|
| This ensures that you don't get an exception on the Close if the open
| failed. The Flush forces the buffer to be written to disk and can avoid
| lines been written out of sequence when the Sub is called from differenrt
| threads. I don't know how this happens but I have observed it
occassionally.
|
| I also tend to prepend the the log message with a timestamp down to
| millisecond level, thus giving some rudimentary performance monitoring
| information:
|
| sw.Writeline("{0:HH:mm:ss.fff} {1}", DateTime.Now, str)
|
| Note that the timestamp here is the time that the Writeline operation
occurs
| rather than the time of 'event' that caused the call to the Sub.
|
| I suggest having a play with it, observing the results and tweaking it to
| your own needs.
|
|
| | > Public Class MyStringLogger
| > Private Shared m_loglock As New Object
| >
| > Public Shared Sub Write(ByVal str As String)
| > SyncLock (m_loglock)
| > Dim sw As New System.io.StreamWriter("c:\validate.log",
| > True)
| > sw.WriteLine(str)
| > sw.Close()
| > End SyncLock
| > End Sub
| > End Class
| >
| > I have a class SessionClass in this program that gets instigated in it's
| > own thread when the program is running. Many of these instances might
be
| > running at the same time each handling a TCP/IP communication session.
| > From within SessionClass I use: MyStringLogger.Write("something worthy
of
| > logging here") to add a line to my log file.
| >
| > It works but does anyone see any potential problems? Comments welcome.
|
|

 

[Jay B. Harlow [MVP - Outlook]]

cj,
As Stephany shows, you should use a Try/Finally to ensure the file is
closed.

With VS 2005 you can use the new Using statement.


| Public Shared Sub Write(ByVal str As String)
| SyncLock (m_loglock)
Using sw As New System.io.StreamWriter("c:\validate.log",
| True)
| sw.WriteLine(str)
End Using
| End SyncLock
| End Sub

Starting with VS 2005, I recommend the using statement, with VS 2002/2003 I
recommend a Try/Finally.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Public Class MyStringLogger
| Private Shared m_loglock As New Object
|
| Public Shared Sub Write(ByVal str As String)
| SyncLock (m_loglock)
| Dim sw As New System.io.StreamWriter("c:\validate.log",
| True)
| sw.WriteLine(str)
| sw.Close()
| End SyncLock
| End Sub
| End Class
|
| I have a class SessionClass in this program that gets instigated in it's
| own thread when the program is running. Many of these instances might
| be running at the same time each handling a TCP/IP communication
| session. From within SessionClass I use:
| MyStringLogger.Write("something worthy of logging here") to add a line
| to my log file.
|
| It works but does anyone see any potential problems? Comments welcome.

 

[Stephany Young]

Can you amplify on you comment about the 'empty Catch blocks' please Jay. I
don't really know what you mean.

Stephany,
| Catch
| Finally
Be mindful of losing exceptions with empty Catch blocks. I would
recommend:

| SyncLock (m_loglock)
| Dim sw As System.IO.StreamWriter = Nothing
| Try
| sw = New System.I.StreamWriter("c:\validate.log", True)
| sw.Writeline(str)
| sw.Flush()
| Finally
| If sw IsNot Nothing Then sw.Close()
| End Try
| End SyncLock

The IsNot suggests VS 2005, I would recommend the Using statement instead,
see my other post.

--
Hope this helps
Jay [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Cor's comment about getting 'stuck' on the actual physical write to disk
is
| valid, however I would consider it to be low risk.
|
| In my opinion, a more pressing potential problem would be the inability
to
| open the file for appending. This could happen if another process has
the
| file locked.
|
| When I use this technique I work on the principle that if the operation
| suceeds then well and and good but if it doesn't then I'm not going to
lose
| any sleep over it. To achieve this I code, within the Shared Sub:
|
| SyncLock (m_loglock)
| Dim sw As System.IO.StreamWriter = Nothing
| Try
| sw = New System.I.StreamWriter("c:\validate.log", True)
| sw.Writeline(str)
| sw.Flush()
| Catch
| Finally
| If sw IsNot Nothing Then sw.Close()
| End Try
| End SyncLock
|
| This ensures that you don't get an exception on the Close if the open
| failed. The Flush forces the buffer to be written to disk and can avoid
| lines been written out of sequence when the Sub is called from
differenrt
| threads. I don't know how this happens but I have observed it
occassionally.
|
| I also tend to prepend the the log message with a timestamp down to
| millisecond level, thus giving some rudimentary performance monitoring
| information:
|
| sw.Writeline("{0:HH:mm:ss.fff} {1}", DateTime.Now, str)
|
| Note that the timestamp here is the time that the Writeline operation
occurs
| rather than the time of 'event' that caused the call to the Sub.
|
| I suggest having a play with it, observing the results and tweaking it
to
| your own needs.
|
|
| | > Public Class MyStringLogger
| > Private Shared m_loglock As New Object
| >
| > Public Shared Sub Write(ByVal str As String)
| > SyncLock (m_loglock)
| > Dim sw As New
System.io.StreamWriter("c:\validate.log",
| > True)
| > sw.WriteLine(str)
| > sw.Close()
| > End SyncLock
| > End Sub
| > End Class
| >
| > I have a class SessionClass in this program that gets instigated in
it's
| > own thread when the program is running. Many of these instances might
be
| > running at the same time each handling a TCP/IP communication session.
| > From within SessionClass I use: MyStringLogger.Write("something worthy
of
| > logging here") to add a line to my log file.
| >
| > It works but does anyone see any potential problems? Comments
welcome.
|
|

 

[Jay B. Harlow [MVP - Outlook]]

The catch block will catch all exceptions, your catch block is empty, any
exceptions within the try block will "mysteriously" disappear, possibly
hiding problems in your code.

Some developers refer to this phenonom as "swallowing exceptions", as your
catch block is swallows (eats) the exception.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp07192001.asp

http://blogs.msdn.com/ericgu/archive/2004/03/16/90712.aspx

When you swallow exceptions, higher level exceptions handlers do not have a
chance to respond to the exception, such as logging or preventing other
exceptions from happening.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Can you amplify on you comment about the 'empty Catch blocks' please Jay.
I
| don't really know what you mean.
|
|
| message | > Stephany,
| > | Catch
| > | Finally
| > Be mindful of losing exceptions with empty Catch blocks. I would
| > recommend:
| >
| > | SyncLock (m_loglock)
| > | Dim sw As System.IO.StreamWriter = Nothing
| > | Try
| > | sw = New System.I.StreamWriter("c:\validate.log", True)
| > | sw.Writeline(str)
| > | sw.Flush()
| > | Finally
| > | If sw IsNot Nothing Then sw.Close()
| > | End Try
| > | End SyncLock
| >
| > The IsNot suggests VS 2005, I would recommend the Using statement
instead,
| > see my other post.
| >
| > --
| > Hope this helps
| > Jay [MVP - Outlook]
| > .NET Application Architect, Enthusiast, & Evangelist
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
| > | > | Cor's comment about getting 'stuck' on the actual physical write to
disk
| > is
| > | valid, however I would consider it to be low risk.
| > |
| > | In my opinion, a more pressing potential problem would be the
inability
| > to
| > | open the file for appending. This could happen if another process has
| > the
| > | file locked.
| > |
| > | When I use this technique I work on the principle that if the
operation
| > | suceeds then well and and good but if it doesn't then I'm not going to
| > lose
| > | any sleep over it. To achieve this I code, within the Shared Sub:
| > |
| > | SyncLock (m_loglock)
| > | Dim sw As System.IO.StreamWriter = Nothing
| > | Try
| > | sw = New System.I.StreamWriter("c:\validate.log", True)
| > | sw.Writeline(str)
| > | sw.Flush()
| > | Catch
| > | Finally
| > | If sw IsNot Nothing Then sw.Close()
| > | End Try
| > | End SyncLock
| > |
| > | This ensures that you don't get an exception on the Close if the open
| > | failed. The Flush forces the buffer to be written to disk and can
avoid
| > | lines been written out of sequence when the Sub is called from
| > differenrt
| > | threads. I don't know how this happens but I have observed it
| > occassionally.
| > |
| > | I also tend to prepend the the log message with a timestamp down to
| > | millisecond level, thus giving some rudimentary performance monitoring
| > | information:
| > |
| > | sw.Writeline("{0:HH:mm:ss.fff} {1}", DateTime.Now, str)
| > |
| > | Note that the timestamp here is the time that the Writeline operation
| > occurs
| > | rather than the time of 'event' that caused the call to the Sub.
| > |
| > | I suggest having a play with it, observing the results and tweaking it
| > to
| > | your own needs.
| > |
| > |
| > | | > | > Public Class MyStringLogger
| > | > Private Shared m_loglock As New Object
| > | >
| > | > Public Shared Sub Write(ByVal str As String)
| > | > SyncLock (m_loglock)
| > | > Dim sw As New
| > System.io.StreamWriter("c:\validate.log",
| > | > True)
| > | > sw.WriteLine(str)
| > | > sw.Close()
| > | > End SyncLock
| > | > End Sub
| > | > End Class
| > | >
| > | > I have a class SessionClass in this program that gets instigated in
| > it's
| > | > own thread when the program is running. Many of these instances
might
| > be
| > | > running at the same time each handling a TCP/IP communication
session.
| > | > From within SessionClass I use: MyStringLogger.Write("something
worthy
| > of
| > | > logging here") to add a line to my log file.
| > | >
| > | > It works but does anyone see any potential problems? Comments
| > welcome.
| > |
| > |
| >
| >
|
|

 

[Stephany Young]

Yes of course - that goes without saying.

If you refer back to my post you will see that 'if the operation
suceeds then well and and good but if it doesn't then I'm not going to lose
any sleep over it'. In otherwords, if an exception occurs while writing the
line to the log file then I don't care. The empty 'Catch' block is included
specifically so that any exceptions thrown in the 'Try' block go down the
big black hole of nul. The conditional Close of the Streamwriter is designed
so that it does not fail if the StreamWriter object failed to instantiate.

The catch block will catch all exceptions, your catch block is empty, any
exceptions within the try block will "mysteriously" disappear, possibly
hiding problems in your code.

Some developers refer to this phenonom as "swallowing exceptions", as
your
catch block is swallows (eats) the exception.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp07192001.asp

http://blogs.msdn.com/ericgu/archive/2004/03/16/90712.aspx

When you swallow exceptions, higher level exceptions handlers do not have
a
chance to respond to the exception, such as logging or preventing other
exceptions from happening.

--
Hope this helps
Jay [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Can you amplify on you comment about the 'empty Catch blocks' please
Jay.
I
| don't really know what you mean.
|
|
| message | > Stephany,
| > | Catch
| > | Finally
| > Be mindful of losing exceptions with empty Catch blocks. I would
| > recommend:
| >
| > | SyncLock (m_loglock)
| > | Dim sw As System.IO.StreamWriter = Nothing
| > | Try
| > | sw = New System.I.StreamWriter("c:\validate.log", True)
| > | sw.Writeline(str)
| > | sw.Flush()
| > | Finally
| > | If sw IsNot Nothing Then sw.Close()
| > | End Try
| > | End SyncLock
| >
| > The IsNot suggests VS 2005, I would recommend the Using statement
instead,
| > see my other post.
| >
| > --
| > Hope this helps
| > Jay [MVP - Outlook]
| > .NET Application Architect, Enthusiast, & Evangelist
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
| > | > | Cor's comment about getting 'stuck' on the actual physical write to
disk
| > is
| > | valid, however I would consider it to be low risk.
| > |
| > | In my opinion, a more pressing potential problem would be the
inability
| > to
| > | open the file for appending. This could happen if another process
has
| > the
| > | file locked.
| > |
| > | When I use this technique I work on the principle that if the
operation
| > | suceeds then well and and good but if it doesn't then I'm not going
to
| > lose
| > | any sleep over it. To achieve this I code, within the Shared Sub:
| > |
| > | SyncLock (m_loglock)
| > | Dim sw As System.IO.StreamWriter = Nothing
| > | Try
| > | sw = New System.I.StreamWriter("c:\validate.log", True)
| > | sw.Writeline(str)
| > | sw.Flush()
| > | Catch
| > | Finally
| > | If sw IsNot Nothing Then sw.Close()
| > | End Try
| > | End SyncLock
| > |
| > | This ensures that you don't get an exception on the Close if the
open
| > | failed. The Flush forces the buffer to be written to disk and can
avoid
| > | lines been written out of sequence when the Sub is called from
| > differenrt
| > | threads. I don't know how this happens but I have observed it
| > occassionally.
| > |
| > | I also tend to prepend the the log message with a timestamp down to
| > | millisecond level, thus giving some rudimentary performance
monitoring
| > | information:
| > |
| > | sw.Writeline("{0:HH:mm:ss.fff} {1}", DateTime.Now, str)
| > |
| > | Note that the timestamp here is the time that the Writeline
operation
| > occurs
| > | rather than the time of 'event' that caused the call to the Sub.
| > |
| > | I suggest having a play with it, observing the results and tweaking
it
| > to
| > | your own needs.
| > |
| > |
| > | | > | > Public Class MyStringLogger
| > | > Private Shared m_loglock As New Object
| > | >
| > | > Public Shared Sub Write(ByVal str As String)
| > | > SyncLock (m_loglock)
| > | > Dim sw As New
| > System.io.StreamWriter("c:\validate.log",
| > | > True)
| > | > sw.WriteLine(str)
| > | > sw.Close()
| > | > End SyncLock
| > | > End Sub
| > | > End Class
| > | >
| > | > I have a class SessionClass in this program that gets instigated
in
| > it's
| > | > own thread when the program is running. Many of these instances
might
| > be
| > | > running at the same time each handling a TCP/IP communication
session.
| > | > From within SessionClass I use: MyStringLogger.Write("something
worthy
| > of
| > | > logging here") to add a line to my log file.
| > | >
| > | > It works but does anyone see any potential problems? Comments
| > welcome.
| > |
| > |
| >
| >
|
|

 

[Jay B. Harlow [MVP - Outlook]]

| In otherwords, if an exception occurs while writing the
| line to the log file then I don't care.
In which case I would recommend:

| > | > | Try
| > | > | sw = New System.I.StreamWriter("c:\validate.log", True)
| > | > | sw.Writeline(str)
| > | > | sw.Flush()
| > | > | Catch

' Ignore any exceptions that may occur

| > | > | Finally
| > | > | If sw IsNot Nothing Then sw.Close()
| > | > | End Try

This way developers reading your code, or inheriting you code, or even
yourself in 6 months. Know that you wanted exceptions ignored at this
point...

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| Yes of course - that goes without saying.
|
| If you refer back to my post you will see that 'if the operation
| suceeds then well and and good but if it doesn't then I'm not going to
lose
| any sleep over it'. In otherwords, if an exception occurs while writing
the
| line to the log file then I don't care. The empty 'Catch' block is
included
| specifically so that any exceptions thrown in the 'Try' block go down the
| big black hole of nul. The conditional Close of the Streamwriter is
designed
| so that it does not fail if the StreamWriter object failed to instantiate.
|
|
| message | > The catch block will catch all exceptions, your catch block is empty,
any
| > exceptions within the try block will "mysteriously" disappear, possibly
| > hiding problems in your code.
| >
| > Some developers refer to this phenonom as "swallowing exceptions", as
| > your
| > catch block is swallows (eats) the exception.
| >
| >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp07192001.asp
| >
| > http://blogs.msdn.com/ericgu/archive/2004/03/16/90712.aspx
| >
| > When you swallow exceptions, higher level exceptions handlers do not
have
| > a
| > chance to respond to the exception, such as logging or preventing other
| > exceptions from happening.
| >
| > --
| > Hope this helps
| > Jay [MVP - Outlook]
| > .NET Application Architect, Enthusiast, & Evangelist
| > T.S. Bradley - http://www.tsbradley.net
| >
| >
| > | > | Can you amplify on you comment about the 'empty Catch blocks' please
| > Jay.
| > I
| > | don't really know what you mean.
| > |
| > |
in
| > | message | > | > Stephany,
| > | > | Catch
| > | > | Finally
| > | > Be mindful of losing exceptions with empty Catch blocks. I would
| > | > recommend:
| > | >
| > | > | SyncLock (m_loglock)
| > | > | Dim sw As System.IO.StreamWriter = Nothing
| > | > | Try
| > | > | sw = New System.I.StreamWriter("c:\validate.log", True)
| > | > | sw.Writeline(str)
| > | > | sw.Flush()
| > | > | Finally
| > | > | If sw IsNot Nothing Then sw.Close()
| > | > | End Try
| > | > | End SyncLock
| > | >
| > | > The IsNot suggests VS 2005, I would recommend the Using statement
| > instead,
| > | > see my other post.
| > | >
| > | > --
| > | > Hope this helps
| > | > Jay [MVP - Outlook]
| > | > .NET Application Architect, Enthusiast, & Evangelist
| > | > T.S. Bradley - http://www.tsbradley.net
| > | >
| > | >
| > | > | > | > | Cor's comment about getting 'stuck' on the actual physical write
to
| > disk
| > | > is
| > | > | valid, however I would consider it to be low risk.
| > | > |
| > | > | In my opinion, a more pressing potential problem would be the
| > inability
| > | > to
| > | > | open the file for appending. This could happen if another process
| > has
| > | > the
| > | > | file locked.
| > | > |
| > | > | When I use this technique I work on the principle that if the
| > operation
| > | > | suceeds then well and and good but if it doesn't then I'm not
going
| > to
| > | > lose
| > | > | any sleep over it. To achieve this I code, within the Shared Sub:
| > | > |
| > | > | SyncLock (m_loglock)
| > | > | Dim sw As System.IO.StreamWriter = Nothing
| > | > | Try
| > | > | sw = New System.I.StreamWriter("c:\validate.log", True)
| > | > | sw.Writeline(str)
| > | > | sw.Flush()
| > | > | Catch
| > | > | Finally
| > | > | If sw IsNot Nothing Then sw.Close()
| > | > | End Try
| > | > | End SyncLock
| > | > |
| > | > | This ensures that you don't get an exception on the Close if the
| > open
| > | > | failed. The Flush forces the buffer to be written to disk and can
| > avoid
| > | > | lines been written out of sequence when the Sub is called from
| > | > differenrt
| > | > | threads. I don't know how this happens but I have observed it
| > | > occassionally.
| > | > |
| > | > | I also tend to prepend the the log message with a timestamp down
to
| > | > | millisecond level, thus giving some rudimentary performance
| > monitoring
| > | > | information:
| > | > |
| > | > | sw.Writeline("{0:HH:mm:ss.fff} {1}", DateTime.Now, str)
| > | > |
| > | > | Note that the timestamp here is the time that the Writeline
| > operation
| > | > occurs
| > | > | rather than the time of 'event' that caused the call to the Sub.
| > | > |
| > | > | I suggest having a play with it, observing the results and
tweaking
| > it
| > | > to
| > | > | your own needs.
| > | > |
| > | > |
| > | > | | > | > | > Public Class MyStringLogger
| > | > | > Private Shared m_loglock As New Object
| > | > | >
| > | > | > Public Shared Sub Write(ByVal str As String)
| > | > | > SyncLock (m_loglock)
| > | > | > Dim sw As New
| > | > System.io.StreamWriter("c:\validate.log",
| > | > | > True)
| > | > | > sw.WriteLine(str)
| > | > | > sw.Close()
| > | > | > End SyncLock
| > | > | > End Sub
| > | > | > End Class
| > | > | >
| > | > | > I have a class SessionClass in this program that gets instigated
| > in
| > | > it's
| > | > | > own thread when the program is running. Many of these instances
| > might
| > | > be
| > | > | > running at the same time each handling a TCP/IP communication
| > session.
| > | > | > From within SessionClass I use: MyStringLogger.Write("something
| > worthy
| > | > of
| > | > | > logging here") to add a line to my log file.
| > | > | >
| > | > | > It works but does anyone see any potential problems? Comments
| > | > welcome.
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| >
| >
|
|

 

[Cor Ligthert [MVP]]

Stephany

I agree with Jay about this,

I would never use an empty catch statement, without at least a comment why I
did this.

That while I try forever to avoid comments.

Just to show my opinion in this.

Cor

 

[cj]

Thanks for all the suggestions everyone. Thanks for the code Stephany.
Jay has a point on adding a comment that the catch is empty on purpose
which would probably help simple minds like me remember. I'm sure
Stephany doesn't need the reminder, it's obvious to her as it probably
is to many people.

Again great suggestion Stephany and valid point Jay. Oh, and thank you
Cor for the original suggestion. I looked into the queue stuff some but
don't think I'll have time to do that right now. Got to move on. I was
told I need to be using Soap by Wednesday. I swore took a shower daily.
I now understand it has something to do with programming. So I
brought a bar to work this morning. Maybe I need to wash the pc. I
hope I figure it out by Wednesday.