I want to run a block of code after the catch statements regardless of which exception happens but only when some exception happens. So basically it's a finally statement that requires an exception in order to execute. Is there an easy way to do this in visual basic?
How about
Dim isException As Boolean = False
Try
....
Catch ex As ApplicationException
isException = True
....
Catch ex As Exception
isException = True
....
Finally
If (isException)
....
End If
End Try
I don't like it, but how about a nested Try:
Try
Try
....
Catch ex As ApplicationException
Throw
Catch ex As Exception
Throw
End Try
Catch
' This is your "finally"
End Try
The finally block of the If statement will always be called regardless if there is an exception raised or not. MSDN
The only other way to do this is to have another method that accepts an exception as a parameter and call that method from the exception catch.
You could add different exception blocks, like this:
Try
' do operation
' Most specific:
Catch e As ApplicationException
' do something only if ApplicationException has occurred
' Least specific:
Catch e As Exception
Console.WriteLine("{0} Second exception caught.", e);
End Try
Related
i want to customize my own error box and message when an error occur in calling a function .
enter image description here
i try to use try catch an exception but not doing anything
Try
L = objGeoFlowDLL.GFCalc_Main(nInputs, nOutputs, sngInputs, sngOutputs)
Catch ex As Exception
MessageBox.Show(ex.Message)
' Me.Close()
Finally
End Try
Try
L = objGeoFlowDLL.GFCalc_Main(nInputs, nOutputs, sngInputs, sngOutputs)
Catch ex As DivideByZeroException
MessageBox.Show("Custom message to be shown when something is divided by zero.")
Catch ex2 As Exception
MessageBox.Show("Custom message to be shown when any other error occurs.")
End Try
I've set up my exceptions so that an error in the code
Try
Using Client As New WebClient
Client.DownloadFile(sExtract, sDownloadTo)
End Using
Catch ex As Exception
Debug.Print("Failed: " + sExtract)
End Try
isn't throw.
This works fine most of the time, but after like 50-100 of errors, the following exception is shown:
According to the checkbox state "Break when this exception type is thrown", which is not-activated, this exception shouldn't be shown this way, right?
What might cause this behaviour, and how could I change it so that this exception isn't thrown?
Here is an additional image of the QuickWatch:
Try
Dim Client As New WebClient
Client.DownloadFile(sExtract, sDownloadTo)
Catch ex As Exception
Console.writeline(ex.tostring)
End Try
I am using the following code in VB.Net (Winforms) to simply loop through a DataGridView and hide rows that are not needed.
Private Sub Overview_Workstream_Sort_SelectedIndexChanged(sender As Object, e As EventArgs) Handles Overview_Workstream_Sort.SelectedIndexChanged
For Each row In Incident_Persons_List.Rows
If Incident_Persons_List.Rows(CInt(row)).Cells(7).Value.ToString.Contains(Overview_Workstream_Sort.SelectedItem.ToString) Then
Debug.Print("User found in workstream")
Incident_Persons_List.Rows(CInt(row)).Visible = True
Else
Incident_Persons_List.Rows(CInt(row)).Visible = False
End If
Next
End Sub
When the debugger gets to the first line of the IF statement, I get the following error:
An unhandled exception of type
'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
Additional information: Exception has been thrown by the target of an
invocation.
I've been trying everything I can think of to understand why this is. I've looked up the fault, but everyone seems to have completely different issues when this exception is thrown.
Is it something to do with how I am doing a compare?
UPDATE 1
I have removed the For Each and replaced it with For i = 0 to Incident_Persons_list.Rows.Count
I have removed the Cint instruction
The Try/Catch as revealed that the actual exception being thrown is:
Row associated with the currency manager's position cannot be made
invisible.
UPDATE 2
Everything is now working correctly with the below code:
Private Sub Overview_Workstream_Sort_SelectedIndexChanged(sender As Object, e As EventArgs) Handles Overview_Workstream_Sort.SelectedIndexChanged
Try
For i = 0 To Incident_Persons_List.Rows.Count - 1
If Incident_Persons_List.Rows(i).Cells(7).Value.ToString.Contains(Overview_Workstream_Sort.SelectedItem.ToString) Then
Debug.Print("User found in workstream")
Incident_Persons_List.Rows(i).Visible = True
Else
'Your code that will throw the Exception
Incident_Persons_List.CurrentCell = Nothing
Incident_Persons_List.Rows(i).Visible = False
End If
Next
Catch ex As TargetInvocationException
'We only catch this one, so you can catch other exception later on
'We get the inner exception because ex is not helpfull
Dim iEX = ex.InnerException
Debug.Print(iEX.Message)
Catch ex As Exception
Debug.Print(ex.Message)
End Try
End Sub
Thanks for the help!
TargetInvocationException :
The exception that is thrown by methods invoked through reflection
How to find out what's going on (because that exception is not really helpfull) ?
You must surroung the calling block with a Try/Catch structure, and then examine the InnerException caught :
Try
'Your code that will throw the Exception
Catch ex As TargetInvocationException
'We only catch this one, so you can catch other exception later on
'We get the inner exception because ex is not helpfull
Dim iEX = ex.InnerException
'Now you can do some stuff to handle your exception
Catch ex As Exception
'Here you catch other kinds of Exceptions that could occur in your code, if you want to...
End Try
And depending on the InnerException, you can now correct your code.
As your row variable is an enumerated element of Incident_Persons_List.Rows and not an index of the element in the collection I think you should replace.
Incident_Persons_List.Rows(CInt(row))
By
row
Or using a basic for structure instead of foreach. Somethink like
For row = 0 To Incident_Persons_List.Rows.Count - 1 Step 1
//SomeStuff
Next
I'd just like to confirm the logic of this nested try-catch block:
Try
Using dbConn As New SqlConnection With {.ConnectionString = strConnStr}
dbConn.Open()
'Prepare transaction
Try
' Execute transaction
Catch ex As Exception
Try
' Transaction rollback
Catch ex2 As SqlException
' ...
End Try
Finally
dbConn.Dispose()
End Try
End Using
Catch ex As Exception
' ...
End Try
If the database connection fails before the transaction is executed (2nd Try-Catch block), the exception will be caught by the first catch block and will no longer proceed further right?
Is the case in nested Try-Catch blocks, the exceptions are contained inside their own try-catch block? Ie: If the transaction execution fails, it calls the 2nd catch block (which initiates rollback), but it won't call the first catch block yes? Similarly, if the transaction rollback occurs, it will only call its corresponding catch block and not the first two?
when an exception throws, it will be passed to closest catch block Corresponding to try block to handle it. if there is not any catch block to handle the exception or if Corresponding catch block throws exception, it comes out, if there is any try/catch block, exception passes to parent catch block and so on.
Here's the code example :
Try
Throw New FirstException()
Finally
Throw New SecondException()
End Try
I figured out it only throws SecondException out and FirstException just vanishes.
I thought FirstException would be inside InnerException property of SecondException but it appears it is not.
I'm not blocked on anything as I don't really need the FirstException to show up, I'm just rather intrigued about this behaviour.
Is there a way to know SecondException did get thrown first when
catching it all at upper level ?
If the first exception really is overriden by the second, what is the
reason ?
Does it happen in every other language ? Is it logical ?
I guess the primary explanation for why this works this way is that you are never catching your first exception and passing it along the chain. If you have a situation like the above where you may be throwing several exceptions on the way back to the original caller then you have to either catch them as they are thrown (and include them as an inner exception when creating the next one) :
Dim ex1 As Exception = Nothing
Try
Throw New Exception("first exception")
Catch ex As Exception
ex1 = ex
Finally
Throw New Exception("second exception", ex1)
End Try
Or, probably better - just don't throw until you have all of the exceptions figured out:
Dim ex1 As Exception = Nothing
Try
ex1 = New Exception("first exception")
Finally
Throw New Exception("second exception", ex1)
End Try
Throwing and catching exceptions is expensive, so it's probably best to not throw until you're ready to return and just log along the way.
One of the limitations of exception handling in .net is that there is no nice way for code in a Finally block to know what exception, if any, caused the code in the Try block to exit, nor is there any normal way for code in a finally block which does have such information to make it available to code which might throw an exception.
In vb.net, it's possible to kludge things in a manner that works pretty well, even though it looks a bit ugly.
Module ExceptionDemo
Function CopySecondArgToFirstAndReturnFalse(Of T)(ByRef dest As T, src As T) As Boolean
dest = src
Return False
End Function
Function AnnotateExceptionAndReturnFalse(ex As Exception, TryBlockException As Exception) As Boolean
If ex Is Nothing Then Return False ' Should never occur
If TryBlockException Is Nothing Then Return False ' No annotation is required
ex.Data("TryBlockException") = TryBlockException
Return False
End Function
Sub ExceptionTest(MainAction As Action, CleanupAction As Action)
Dim TryBlockException As Exception = Nothing
Try
MainAction()
Catch ex As Exception When CopySecondArgToFirstAndReturnFalse(TryBlockException, ex)
' This block never executes, but above grabs a ref to any exception that occurs
Finally
Try
CleanupAction()
Catch ex As Exception When AnnotateExceptionAndReturnFalse(ex, TryBlockException)
' This block never executes, but above performs necessary annotations
End Try
End Try
End Sub
Sub ExceptionTest2(Message As String, MainAction As Action, CleanupAction As Action)
Debug.Print("Exception test: {0}", Message)
Try
ExceptionTest(MainAction, CleanupAction)
Catch ex As Exception
Dim TryBlockException As Exception = Nothing
Debug.Print("Exception occurred:{0}", ex.ToString)
If ex.Data.Contains("TryBlockException") Then TryBlockException = TryCast(ex.Data("TryBlockException"), Exception)
If TryBlockException IsNot Nothing Then Debug.Print("TryBlockException was:{0}", TryBlockException.ToString)
End Try
Debug.Print("End test: {0}", Message)
End Sub
Sub ExceptionDemo()
Dim SuccessfulAction As Action = Sub()
Debug.Print("Successful action")
End Sub
Dim SuccessfulCleanup As Action = Sub()
Debug.Print("Cleanup is successful")
End Sub
Dim ThrowingAction As Action = Sub()
Debug.Print("Throwing in action")
Throw New InvalidOperationException("Can't make two plus two equal seven")
End Sub
Dim ThrowingCleanup As Action = Sub()
Debug.Print("Throwing in cleanup")
Throw New ArgumentException("That's not an argument--that's just contradiction")
End Sub
ExceptionTest2("Non-exception case", SuccessfulAction, SuccessfulCleanup)
ExceptionTest2("Exception in main; none in cleanup", ThrowingAction, SuccessfulCleanup)
ExceptionTest2("Exception in cleanup only", SuccessfulAction, ThrowingCleanup)
ExceptionTest2("Exception in main and cleanup", ThrowingAction, ThrowingCleanup)
End Sub
End Module
The module above starts with a couple helper modules which should probably be in their own "Exception helpers" module. The ExceptionTest method shows the pattern for code which might throw an exception in both the Try and Finally block. The ExceptionTest2 method calls ExceptionTest and reports what exception if any comes back from it. ExceptionDemo calls ExceptionTest2 in such a way as to cause exceptions in different combinations of the Try and Finally blocks.
As shown, if an exception occurs during cleanup, that exception will be returned to the caller, with the original exception being an item in its Data dictionary. An alternative pattern would be to catch the exception that occurs on cleanup and include it in the data of the original exception (which would be left uncaught). My general inclination is that it's probably better in many cases to propagate the exception that occurs during cleanup, since any code which was planning to deal with the original exception will probably expect that cleanup succeeded; if such an expectation cannot be met, the exception that escapes should probably not be the one the caller was expecting. Note also that the latter approach would require a slightly different method of adding information to the original exception, since an exception which is thrown in a nested Try block might need to hold information about multiple exceptions that were thrown in nested Finally blocks.