Try..Catch..Continue ??

[linesh]

In VB6, there is an option "On Error goto " ..followed by "Resume Next" which is very useful to let the application continue to run and return to the very next line of code though an exception is caught. Is this possible in vb.net or c# within the "Try..Catch" construct?

[snarfblam]

The idea with a try/catch is that if an exception is caught in the try block, none of the remaining code in the try block is valid (i.e. is acceptable to run in this erraneous state). My advice would be to get your hands dirty with try/catch blocks so that you become familiar and comfortable with them, and learn how to use them effectively. If you are worried only about a single line or a few lines of code throwing an exception...

Sub Bad()
  On Error Goto handler
  txtMyTextBox.Text = SomeObject.SomeProperty
  Me.Text &= " [Complete]"
  Return
   
  Handler:
  txtMyTextBox.Text = "(Nothing)"
  Resume Next
End Sub

...you can wrap only those lines with a try/catch...

Sub Better()
  Try
     txtMyTextBox.Text = SomeObject.SomeProperty
  Catch(Ex As NullReferenceException)
     txtMyTextBox.Text = Nothing
  End Try
  Me.Text &= " [Complete]"
End Sub

The latter only catches an error rising from a null reference. With the first, any kind of expection could be thrown, and if it isn't what you were expecting, something bad could happen.

 

If you are worried about any one of many lines throwing an exception, all I have to say is that it is very rare that it can be a good idea to plow through a function regardless of what goes wrong. You should generally identify potential problems, reduce chances of them occuring, and handle the errors that do arise in a manner as specific and appropriate as possible. With VB6-style blanket error handling it is very easy to handle the wrong error the wrong way, which is why it is so often discouraged.

 

But to answer your question: there is no completely analogous method to emulate ResumeNext, except perhaps wrapping each statement in a try/catch block.

[linesh]

That is interesting Marble. I am very familiar with Try..Catch() blocks. I think the Finally block is similar to the Resume Next block little bit. However, one has to be sure no errors will occur inside the Finally block.

[Jaco]

There is an equivalent with try/catch where the catch block is empty, but it may be impractical:

 

Try

statement 1

Catch

'no code (ignore exception)

End Try

Try

statement 2

Catch

'no code (ignore exception)

End Try

 

As you can see, this is not a very elegant solution, but it works.

As marble_eater says, ignoring errors is far from ideal.

[Nerseus]

However, one has to be sure no errors will occur inside the Finally block.

That is definitely true. You would normally only put code in a finally block that you're sure is NOT going to blow up, and that you want to run even if the code in the Try throws an exception (of course).

 

I think wrapping individual lines with Try/Catch is the closest to a "Resume Next" you'll get.

 

I can't for the life of me remember a single time I used Resume Next in VB6 or earlier and I wrote a LOT of code back then :)

I used On Error Goto ErrHandler in almost every function with some semi-standard logging (building a fake stack trace) and "bubbling up" of errors.

 

Typically, if I had a function where I wanted to run a line of code and wanted to continue even if there were errors, I'd wrap that code in a function. For example, if I had a function that converted a string to an int and then used it:

Public Sub Test()
Dim s As String = "123abc"
Dim i As Integer = 0 ' Default to 0 in case Integer.Parse fails - I like to be explicit

   On Error Goto ErrHandler
   i = Integer.Parse(s)
   ' Do something with i
   Return

ErrHandler:
   Resume Next
End Sub

 

I would rather write it like this:

Public Sub Test()
Dim s As String = "123abc"
Dim i As Integer

   i = GetInt(s)
   ' Do something with i
End Sub

Public Function GetInt(ByVal s As String) As Integer
   Try
       Return Integer.Parse(s)
   Catch
       Return 0
   End Try
End Function

 

That way the code in Test() is more readable and doesn't worry about errors.

 

-ner