resume next in VB.NET ?

[fniles]

In VB 6 I can do the following:

Sub MySub
on error goto Err1
: --> all my codes are here
: --> say this is where the error occurs
: --> this is where resume next will bring me after Err1
exit sub

Err1:
msgbox "error = " & error
resume next
end sub

With the above codes, when I get an error, it did not exit out of my
subroutine, instead I will go to the next statement after I get the error.
Can I do the same thing in VB.NET 2005 ? Thank you.

Currently in VB.NET, this is what I do:

Sub MySub
try
: --> all my codes are here
Catch ex As Exception
Try
swError = New StreamWriter(Application.StartupPath &
"\Log.txt", True)
swError.WriteLine(Now & " error = " & ex.Message)
swError.Close()
swError = Nothing
Catch ex2 As Exception
End Try
End Try
End Sub

With the above code, if I get an error, it will exit the sub and will not
execute the rest of the code in my subroutine.

 

[Armin Zingler]

In VB 6 I can do the following:

Sub MySub
on error goto Err1
: --> all my codes are here
: --> say this is where the error occurs
: --> this is where resume next will bring me after Err1
exit sub

Err1:
msgbox "error = " & error
resume next
end sub

With the above codes, when I get an error, it did not exit out of my
subroutine, instead I will go to the next statement after I get the
error. Can I do the same thing in VB.NET 2005 ? Thank you.

Currently in VB.NET, this is what I do:

Sub MySub
try
: --> all my codes are here
Catch ex As Exception
Try
swError = New StreamWriter(Application.StartupPath &
"\Log.txt", True)
swError.WriteLine(Now & " error = " & ex.Message)
swError.Close()
swError = Nothing
Catch ex2 As Exception
End Try
End Try
End Sub

With the above code, if I get an error, it will exit the sub and
will not execute the rest of the code in my subroutine.

It's probably very rare that one wants to ignore errors in multiple
consecutive lines. I think the only way to recreate the VB6 behavior is:

try
statment #1
catch 'note: no "ex as exception" necessary
end try

try
statment #2
catch
end try

And so on. However, I see, if you wanted to do the same error handling
in each catch block, you'd have to write the same each time.


Armin

 

[Nabil]

In VB 6 I can do the following:

Sub MySub
on error goto Err1
    :  --> all my codes are here
    :  --> say this is where the error occurs
    : --> this is where resume next will bring me after Err1
exit sub

Err1:
    msgbox "error = " & error
    resume next
end sub

With the above codes, when I get an error, it did not exit out of my
subroutine, instead I will go to the next statement after I get the error.
Can I do the same thing in VB.NET 2005 ? Thank you.

Currently in VB.NET, this is what I do:

Sub MySub
        try
        :  --> all my codes are here
        Catch ex As Exception
            Try
                swError = New StreamWriter(Application.StartupPath &
"\Log.txt", True)
                swError.WriteLine(Now & " error = " & ex..Message)
                swError.Close()
                swError = Nothing
            Catch ex2 As Exception
            End Try
        End Try
End Sub

With the above code, if I get an error, it will exit the sub and will not
execute the rest of the code in my subroutine.

You should put Try and Catch around all code you suspect may cause an
error. So

Try
: --> one line of code that you need to catch errors on
Catch ex2 As Exception
End Try

Try
: --> one line of code that you need to catch errors on
Catch exc as Exception
End Try

You can also put in a Finally clause that will run whether there is an
exception or not!

Good luck!

 

[AMercer]

I agree with other responders about try-catch being a better construct. That
said, with breakpoints on the two commented statements below, the behavior
you want happens. The i\j error occurs, then a branch to err1, and finally
resume next back in sequence.

Sub MySub()
Dim i, j, k As Integer
On Error GoTo err1
k = i \ j
k = k ' break here second
Return
err1:
k = k ' break here first
Resume Next
End Sub

 

[Phill W.]

Sub MySub
Try
--> all my codes are here
Catch ex As Exception
Try
swError = New StreamWriter(Application.StartupPath &
"\Log.txt", True)
swError.WriteLine(Now & " error = " & ex.Message)
swError.Close()
swError = Nothing
Catch ex2 As Exception
End Try
End Try
End Sub

With the above code, if I get an error, it will exit the sub and will not
execute the rest of the code in my subroutine.

Correct. You have to wrap your Exception handling as "tightly" around
the [potential] source of the error as you can, even if that's around a
single call to a.n.other function.

Also:

If you need to support Vista (with UAC in place) any time soon, think
twice about logging into the application's "own" directory. "Regular"
Users won't have permission to write anything under "Program Files" so
your StreamWriter creation could well fail .

Setting swError to Nothing has no useful effect. Close() has already
called Dispose() on the StreamWriter and the underlying FileStream.

HTH,
Phill W.

 

[sloan]

I'm not trying to be mean, but .. you need a HEAVY DOSE of how to handle
exceptions in DotNet.

Read and bookmark this page:
http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx

...

Throw out your VB6 mentality all together. Just because you ~can~ in
VB.NET, doesn't mean you should.

...

 

[Martin H.]

Hello Phill,

If you need to support Vista (with UAC in place) any time soon, think
twice about logging into the application's "own" directory. "Regular"
Users won't have permission to write anything under "Program Files" so
your StreamWriter creation could well fail .

This is not just with Windows Vista, but also With XP (and also with
2000/NT AFAIK). I really wonder, why this reduced right thingy is always
mentioned in combination with Vista... If you use a limited account with
XP (as you should) you also can't write into the "Program files" directory.

Therefore:

- if you need to share write access for files among users, write into
"C:\Documents and Settings\All Users\Application Data"

- if you need to write files for each user separately, write into
"C:\Documents and Settings\<User name>\Application Data"

Since MS can change the paths at their own discretion (as they did with
Vista - there it is C:\Users\...) it is always a good idea to get the
path from the .NET framework.

ApplicationData directory for the running program under the logged-in user:
My.Computer.FileSystem.SpecialDirectories.CurrentUserApplicationData
(=C:\Documents and Settings\<User name>\Application
Data\Company\ProgramName\Version)

ApplicationData directory for the logged-in user:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
(=C:\Documents and Settings\<User name>\Application Data)

ApplicationData directory for all users:
Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)
(=C:\Documents and Settings\All Users\Application Data)

Best regards,

Martin

 

[fniles]

Thank you.

try
statment #1
catch 'note: no "ex as exception" necessary
end try

Does it mean that I want to do the above codes for each line of the codes ?

 

[Tom Shelton]

Hello Phill,


This is not just with Windows Vista, but also With XP (and also with
2000/NT AFAIK). I really wonder, why this reduced right thingy is always
mentioned in combination with Vista... If you use a limited account with
XP (as you should) you also can't write into the "Program files" directory.

I think because the restrictions are tighter under Vista. It fails even
as an admin account - which wasn't the case on XP.

In other words, you have to do the right thing always....

 

[Cor Ligthert[MVP]]

Fniles,

I think that you have learned yourself a very bad way of creating code.

It would in my idea be nicer when you did it like this.

\\\
Sub
All your code that cannot throw an exception here
Try
swError = new StreamWriter(.....
Try
swError.Write line
Catch
'here you handle the writting errors
End Try
Catch
'here you handle the opening errors
Finally
'here you do the code as closing
'where setting something to nothing is as well a bad habit.
End Try
End Sub
///

If you have in one of these routines errors, then there is nothing to
resume.

Cor

 

[Phill W.]

Does it mean that I want to do the above codes for each line of the codes ?

No. Not in that form, anyway.

This is the equivalent of "On Error Resume Next" with /no/ error
handling of any kind, something like this ...

On Error Resume Next
Statement1
Statement2
Statement3
' and so on

.... only worse. The Exception - whatever it might have been - only
exists for the duration of the Catch block (unless you Throw it again)
so, by the time you hit "End Try", it's /evaporated/ as if it never
happened:

Try
Statement1
Catch
End Try
' Even if Statement1 went wrong, we /don't/ know about it!!

Try
Statement2
Catch
End Try
' Even if Statement2 went wrong, we /don't/ know about it!!

So the above could work, so long as you put /something/ in the Catch
blocks.


Having said all that, might it not be better to push the Try..Catch
constructs into the routines that you're /calling/ instead?

Sub X()
Statement1()
Statement2()
End Sub

Sub Statement1()
Try
' whatever
Catch ex as Exception
End Try
End Sub

(and the same for Statement2())

Any Exception gets caught in the [called] routine and your main routine
never gets to see it (because it's been "handled" already).

HTH,
Phill W.