-
Oct 27th, 2013, 10:28 AM
#1
Thread Starter
Fanatic Member
[RESOLVED] Suppressing workflow exceptions from being logged
Hello everyone. I am dealing with a very multithreaded environment at the moment, and as you may expect, this involves the complicated subject of properly aborting a thread.
Now I know that calling .Abort() on it is not the way to go, so that is not what I do. Instead I have a variable declared that states whether a thread should continue or not.
When aborting, it's a simple process of changing this state and calling Join() on the Thread.
Example, this is in an Image frame storing class that also handles the animation:
Code:
Private Sub UpdateAnimation()
Try
While Not disposedValue
Dim now As Date = Date.Now
If now.Subtract(Me.m_lastFrameChange).TotalMilliseconds >= Me.m_frameDelays(Me.m_frameIndex) Then
Me.m_lastFrameChange = now
If Me.m_frameIndex = Me.m_frameTotal - 1 Then
Me.CurrentFrame = 0
Else
Me.CurrentFrame += 1
End If
End If
Threading.Thread.Sleep(50)
End While
Catch ex As System.Threading.ThreadInterruptedException
End Try
End Sub
To abort:
Code:
Me.disposedValue = True
' ... some other disposing logic ...
Me.m_animateThread.Interrupt()
Me.m_animateThread.Join()
Now what is the issue? The Interrupt. In my IDE it spams a pointless message despite it being handled in the Try-Catch:
Code:
A first chance exception of type 'System.Threading.ThreadInterruptedException' occurred in mscorlib.dll
A first chance exception of type 'System.Threading.ThreadInterruptedException' occurred in mscorlib.dll
A first chance exception of type 'System.Threading.ThreadInterruptedException' occurred in mscorlib.dll
A first chance exception of type 'System.Threading.ThreadInterruptedException' occurred in mscorlib.dll
Is there any way to COMPLETELY hide this exception from the debugger?
It heavily spams my IDE and masks any legitimate runtime exceptions or debugging information to be shown.
I've run into the same issue with invoking on controls where the control is disposed...it forced me to do complicated event handling and SyncLocking to abort whatever thread from invoking things.
In this case, however, the interrupt is needed to avoid wasting 50ms of a thread waiting period. The message forces me not to do it though...
An alternative way of interrupting a Wait that does not cause an exception logged is fine, too.
Last edited by bergerkiller; Oct 27th, 2013 at 10:31 AM.
Reason: Moved try-catch
-
Nov 6th, 2013, 01:21 PM
#2
Thread Starter
Fanatic Member
Re: Suppressing workflow exceptions from being logged
I've solved the problem for now by using a different kind of waiting system (with wait objects). I am still interested in whether there is a way to suppress exceptions from being debug-logged, though.
-
Nov 7th, 2013, 07:17 AM
#3
Re: Suppressing workflow exceptions from being logged
I wouldn't use Thread.Interrupt. Try this pattern:
Code:
Dim StopUpdateAnimation As New Threading.ManualResetEvent(False)
Private Sub UpdateAnimation()
Do
'your code minus try catch for .Interrupt
'
'
Loop While Not StopUpdateAnimation.WaitOne(50)
End Sub
'to stop thread
StopUpdateAnimation.Set()
-
Nov 7th, 2013, 12:43 PM
#4
Re: Suppressing workflow exceptions from being logged
perhaps you shouldn't be ignoring errors in the first place... that's what this code does:
Code:
Catch ex As System.Threading.ThreadInterruptedException
End Try
THat's where those are coming from... personally (and this is just my opinion) I'd remove the error handler for the moment, let those exceptions happen... find out WHY they are happening, and then attempt to re-structure the code so that the error doesn't happen in the first place.
And then I'd vow to never ever again use an empty catch to ignore exceptions.
-tg
-
Nov 7th, 2013, 12:57 PM
#5
Re: Suppressing workflow exceptions from being logged
Originally Posted by techgnome
perhaps you shouldn't be ignoring errors in the first place... that's what this code does:
Code:
Catch ex As System.Threading.ThreadInterruptedException
End Try
THat's where those are coming from... personally (and this is just my opinion) I'd remove the error handler for the moment, let those exceptions happen... find out WHY they are happening, and then attempt to re-structure the code so that the error doesn't happen in the first place.
And then I'd vow to never ever again use an empty catch to ignore exceptions.
-tg
The reason for those particular errors is because of the way it is structured, i.e. using xyzThread.Interrupt. I agree about the empty handler.
-
Nov 8th, 2013, 12:10 PM
#6
Thread Starter
Fanatic Member
Re: Suppressing workflow exceptions from being logged
I agree, for that reason I often try to avoid empty catches as much as possible. Often times though, you need a way to 'quickly' abort a certain operation, for example when a form closes or is closed. With multithreading this tends to become an issue, as it is still in the middle of interacting with an object it just found out got disposed.
Often times this sort of thing can not be prevented: there is no control event fired right before disposing. At that time the only way to put everything to a halt is to catch the exception thrown when invoke is executed...but this results in your console ending up full of errors.
Yeah, these are the kind of exceptions that should not be workflow exceptions, but become them because that is pretty much their only purpose. And you don't want your program crash randomly because you forgot to try-catch an invoke instruction.
Like I mentioned, I started using the 'wait object', which @dbasnett posted as well. For my problem mentioned in the OP this is indeed the best way to go around it. I do wonder what the purpose of that Thread.interrupt() even is, if it can't be used for aborting a thread. Marked as resolved.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|