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.Strea mWriter("c:\val idate.log",
True)
sw.WriteLine(st r)
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("somethin g 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/lib...ons.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.Strea mWriter = Nothing
Try
sw = New System.I.Stream Writer("c:\vali date.log", True)
sw.Writeline(st r)
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.
"cj" <[e-mail] am> wrote in message
news:e%******** ********@TK2MSF TNGP15.phx.gbl. ..

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.Strea mWriter("c:\val idate.log",
True)
sw.WriteLine(st r)
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("somethin g worthy of
logging here") to add a line to my log file.

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

[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

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

Date: Thu, 23 Feb 2006 11:29:40 -0500
From: cj <[e-mail] am>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
Subject: Does this look good?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <e#************ **@TK2MSFTNGP15 .phx.gbl>
Newsgroups: microsoft.publi c.dotnet.langua ges.vb
NNTP-Posting-Host: 208.254.170.98
Lines: 1
Path: TK2MSFTNGXA01.p hx.gbl!TK2MSFTN GP08.phx.gbl!TK 2MSFTNGP15.phx. gbl
Xref: TK2MSFTNGXA01.p hx.gbl microsoft.publi c.dotnet.langua ges.vb:319203
X-Tomcat-NG: microsoft.publi c.dotnet.langua ges.vb

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.Strea mWriter("c:\val idate.log",
True)
sw.WriteLine(st r)
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("somethi ng 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]]

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

| SyncLock (m_loglock)
| Dim sw As System.IO.Strea mWriter = Nothing
| Try
| sw = New System.I.Stream Writer("c:\vali date.log", True)
| sw.Writeline(st r)
| 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
"Stephany Young" <noone@localhos t> wrote in message
news:Oe******** ******@TK2MSFTN GP14.phx.gbl...
| 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.Strea mWriter = Nothing
| Try
| sw = New System.I.Stream Writer("c:\vali date.log", True)
| sw.Writeline(st r)
| 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.
|
|
| "cj" <[e-mail] am> wrote in message
| news:e%******** ********@TK2MSF TNGP15.phx.gbl. ..
| > 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.Strea mWriter("c:\val idate.log",
| > True)
| > sw.WriteLine(st r)
| > 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("somethin g 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.Strea mWriter("c:\val idate.log",
| True)
| sw.WriteLine(st r)
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
"cj" <[e-mail] am> wrote in message
news:e%******** ********@TK2MSF TNGP15.phx.gbl. ..
| 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.Strea mWriter("c:\val idate.log",
| True)
| sw.WriteLine(st r)
| 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("somethin g 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.
"Jay B. Harlow [MVP - Outlook]" <Ja************ @tsbradley.net> wrote in
message news:eX******** ******@TK2MSFTN GP09.phx.gbl...

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

| SyncLock (m_loglock)
| Dim sw As System.IO.Strea mWriter = Nothing
| Try
| sw = New System.I.Stream Writer("c:\vali date.log", True)
| sw.Writeline(st r)
| 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
"Stephany Young" <noone@localhos t> wrote in message
news:Oe******** ******@TK2MSFTN GP14.phx.gbl...
| 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.Strea mWriter = Nothing
| Try
| sw = New System.I.Stream Writer("c:\vali date.log", True)
| sw.Writeline(st r)
| 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.
|
|
| "cj" <[e-mail] am> wrote in message
| news:e%******** ********@TK2MSF TNGP15.phx.gbl. ..
| > 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.Strea mWriter("c:\val idate.log",
| > True)
| > sw.WriteLine(st r)
| > 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("somethin g 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 "mysterious ly" 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/de...rp07192001.asp

http://blogs.msdn.com/ericgu/archive.../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
"Stephany Young" <noone@localhos t> wrote in message
news:uJ******** ********@TK2MSF TNGP11.phx.gbl. ..
| Can you amplify on you comment about the 'empty Catch blocks' please Jay.
I
| don't really know what you mean.
|
|
| "Jay B. Harlow [MVP - Outlook]" <Ja************ @tsbradley.net> wrote in
| message news:eX******** ******@TK2MSFTN GP09.phx.gbl...
| > Stephany,
| > | Catch
| > | Finally
| > Be mindful of losing exceptions with empty Catch blocks. I would
| > recommend:
| >
| > | SyncLock (m_loglock)
| > | Dim sw As System.IO.Strea mWriter = Nothing
| > | Try
| > | sw = New System.I.Stream Writer("c:\vali date.log", True)
| > | sw.Writeline(st r)
| > | 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
| >
| >
| > "Stephany Young" <noone@localhos t> wrote in message
| > news:Oe******** ******@TK2MSFTN GP14.phx.gbl...
| > | 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.Strea mWriter = Nothing
| > | Try
| > | sw = New System.I.Stream Writer("c:\vali date.log", True)
| > | sw.Writeline(st r)
| > | 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.
| > |
| > |
| > | "cj" <[e-mail] am> wrote in message
| > | news:e%******** ********@TK2MSF TNGP15.phx.gbl. ..
| > | > 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.Strea mWriter("c:\val idate.log",
| > | > True)
| > | > sw.WriteLine(st r)
| > | > 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("somethin g
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.
"Jay B. Harlow [MVP - Outlook]" <Ja************ @tsbradley.net> wrote in
message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

The catch block will catch all exceptions, your catch block is empty, any
exceptions within the try block will "mysterious ly" 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/de...rp07192001.asp

http://blogs.msdn.com/ericgu/archive.../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
"Stephany Young" <noone@localhos t> wrote in message
news:uJ******** ********@TK2MSF TNGP11.phx.gbl. ..
| Can you amplify on you comment about the 'empty Catch blocks' please
Jay.
I
| don't really know what you mean.
|
|
| "Jay B. Harlow [MVP - Outlook]" <Ja************ @tsbradley.net> wrote in
| message news:eX******** ******@TK2MSFTN GP09.phx.gbl...
| > Stephany,
| > | Catch
| > | Finally
| > Be mindful of losing exceptions with empty Catch blocks. I would
| > recommend:
| >
| > | SyncLock (m_loglock)
| > | Dim sw As System.IO.Strea mWriter = Nothing
| > | Try
| > | sw = New System.I.Stream Writer("c:\vali date.log", True)
| > | sw.Writeline(st r)
| > | 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
| >
| >
| > "Stephany Young" <noone@localhos t> wrote in message
| > news:Oe******** ******@TK2MSFTN GP14.phx.gbl...
| > | 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.Strea mWriter = Nothing
| > | Try
| > | sw = New System.I.Stream Writer("c:\vali date.log", True)
| > | sw.Writeline(st r)
| > | 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.
| > |
| > |
| > | "cj" <[e-mail] am> wrote in message
| > | news:e%******** ********@TK2MSF TNGP15.phx.gbl. ..
| > | > 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.Strea mWriter("c:\val idate.log",
| > | > True)
| > | > sw.WriteLine(st r)
| > | > 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("somethin g
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.Stream Writer("c:\vali date.log", True)
| > | > | sw.Writeline(st r)
| > | > | 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
"Stephany Young" <noone@localhos t> wrote in message
news:OF******** ******@TK2MSFTN GP14.phx.gbl...
| 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.
|
|
| "Jay B. Harlow [MVP - Outlook]" <Ja************ @tsbradley.net> wrote in
| message news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..
| > The catch block will catch all exceptions, your catch block is empty,
any
| > exceptions within the try block will "mysterious ly" 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/de...rp07192001.asp
| >
| > http://blogs.msdn.com/ericgu/archive.../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
| >
| >
| > "Stephany Young" <noone@localhos t> wrote in message
| > news:uJ******** ********@TK2MSF TNGP11.phx.gbl. ..
| > | Can you amplify on you comment about the 'empty Catch blocks' please
| > Jay.
| > I
| > | don't really know what you mean.
| > |
| > |
| > | "Jay B. Harlow [MVP - Outlook]" <Ja************ @tsbradley.net> wrote
in
| > | message news:eX******** ******@TK2MSFTN GP09.phx.gbl...
| > | > Stephany,
| > | > | Catch
| > | > | Finally
| > | > Be mindful of losing exceptions with empty Catch blocks. I would
| > | > recommend:
| > | >
| > | > | SyncLock (m_loglock)
| > | > | Dim sw As System.IO.Strea mWriter = Nothing
| > | > | Try
| > | > | sw = New System.I.Stream Writer("c:\vali date.log", True)
| > | > | sw.Writeline(st r)
| > | > | 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
| > | >
| > | >
| > | > "Stephany Young" <noone@localhos t> wrote in message
| > | > news:Oe******** ******@TK2MSFTN GP14.phx.gbl...
| > | > | 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.Strea mWriter = Nothing
| > | > | Try
| > | > | sw = New System.I.Stream Writer("c:\vali date.log", True)
| > | > | sw.Writeline(st r)
| > | > | 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.
| > | > |
| > | > |
| > | > | "cj" <[e-mail] am> wrote in message
| > | > | news:e%******** ********@TK2MSF TNGP15.phx.gbl. ..
| > | > | > 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.Strea mWriter("c:\val idate.log",
| > | > | > True)
| > | > | > sw.WriteLine(st r)
| > | > | > 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("somethin g
| > worthy
| > | > of
| > | > | > logging here") to add a line to my log file.
| > | > | >
| > | > | > It works but does anyone see any potential problems? Comments
| > | > welcome.
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| >
| >
|
|