error trapping not working

[aaron]

On Winxp Pro
I try to trap an error:

On error resume next
If (Err.Number <> 0) Then
End sub
End If

but no matter what the case Err.Number = 0. When I was using visual basic
6.0 on a win2k pro computer, errors were returned with values other than 0.
Is there a patch I need to download or do I need to upgrade to VB.Net or
something?

[Raoul Watson]

"aaron" <at******@yahoo.com> wrote in message
news:c4**********@nntp6.u.washington.edu...

On Winxp Pro
I try to trap an error:

On error resume next
If (Err.Number <> 0) Then
End sub
End If

but no matter what the case Err.Number = 0. When I was using visual basic
6.0 on a win2k pro computer, errors were returned with values other than 0. Is there a patch I need to download or do I need to upgrade to VB.Net or
something?

"resume next" means exactly that.. continue with the next statement so it
can't catch errors (basically you are ignoring errors). What you might want
to do to catch errors is probably:

Sub SomeSub()
On Error GoTo ErrorHan

'code which may generate error

Exit Sub

ErrorHan:
Select Case Err.Number ' Evaluate error number.
Case xx 'handle it
Case 'etc
End Select

Resume

End Sub

[J French]

On Wed, 31 Mar 2004 02:55:39 GMT, "Raoul Watson"
<Wa*****@IntelligenCIA.com> wrote:
<snip>

"resume next" means exactly that.. continue with the next statement so it
can't catch errors (basically you are ignoring errors). What you might want
to do to catch errors is probably:

Sub SomeSub()
On Error GoTo ErrorHan

'code which may generate error

Exit Sub

ErrorHan:
Select Case Err.Number ' Evaluate error number.
Case xx 'handle it
Case 'etc
End Select

Resume

Raoul, I totally disagree, both with what you say about
On Error Resume Next
and your 'improved' alternative

I suggest that you check out On Error Resume Next very carefully
- you will find that
a) it works
b) use of it makes simpler code

To the OP - try this

Private Sub Command1_Click()
Dim I As Integer

On Error Resume Next
I = I / 0
If Err Then MsgBox Err.Description

End Sub

[aaron]

Thanks, with your hints I found that the problem is the error is not being
passed to my other function. How do I pass an error object or what is the
best way to pass an error if I want to pass both the description and the
number? I have:

Sub SomeSub()
On Error Resume Next

'code that generates error

If Err Then
MyError(Err) 'pass error object????
End If
End Sub
---------------------------
Sub MyError (MyErrorObject as ErrObject)

msgbox MyErrorObject.number 'it is always 0 because it's not being passed

End Sub

Thanks!

"J French" <er*****@nowhere.com> wrote in message
news:40****************@news.btclick.com...

On Wed, 31 Mar 2004 02:55:39 GMT, "Raoul Watson"
<Wa*****@IntelligenCIA.com> wrote:
<snip>

"resume next" means exactly that.. continue with the next statement so it
can't catch errors (basically you are ignoring errors). What you might wantto do to catch errors is probably:

Sub SomeSub()
On Error GoTo ErrorHan

'code which may generate error

Exit Sub

ErrorHan:
Select Case Err.Number ' Evaluate error number.
Case xx 'handle it
Case 'etc
End Select

Resume

Raoul, I totally disagree, both with what you say about
On Error Resume Next
and your 'improved' alternative

I suggest that you check out On Error Resume Next very carefully
- you will find that
a) it works
b) use of it makes simpler code

To the OP - try this

Private Sub Command1_Click()
Dim I As Integer

On Error Resume Next
I = I / 0
If Err Then MsgBox Err.Description

End Sub

[Larry Serflaten]

"aaron" <at******@yahoo.com> wrote

Thanks, with your hints I found that the problem is the error is not being
passed to my other function. How do I pass an error object or what is the
best way to pass an error if I want to pass both the description and the
number? I have:

The Err Object is a global object. You should not pass it as a parameter.
The called sub will see the same error object that was present in the
caller routine. If you want to clear the error for use in your called sub,
then you will have to store the Err object values before you do anything
that would clear them out.

LFS


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Raoul Watson]

"J French" <er*****@nowhere.com> wrote in message
news:40****************@news.btclick.com...

On Wed, 31 Mar 2004 02:55:39 GMT, "Raoul Watson"
<Wa*****@IntelligenCIA.com> wrote:
<snip>

"resume next" means exactly that.. continue with the next statement so it
can't catch errors (basically you are ignoring errors). What you might wantto do to catch errors is probably:

Sub SomeSub()
On Error GoTo ErrorHan

'code which may generate error

Exit Sub

ErrorHan:
Select Case Err.Number ' Evaluate error number.
Case xx 'handle it
Case 'etc
End Select

Resume

Raoul, I totally disagree, both with what you say about
On Error Resume Next
and your 'improved' alternative

I am not sure you read my post carefully.

1. My method is not "improved" that's a standard method. Even the VB help
file will show you a similar code for "on error". I have been using that
method over 25 years.

2. I never said On error resume next doesn't work, I use it all the time,
but like I said it resumes with the next statement so in essence "ignoring"
the error. For example:

On error resume next
open "filedoesntexist" for input as #1
debug.print "we get here even if file doesn't exist".
I suggest that you check out On Error Resume Next very carefully
- you will find that
a) it works

See above.

Your method is fine too. I don't have a problem with you having the "last
word".

[Bob Butler]

er*****@nowhere.com (J French) wrote in message news:<40****************@news.btclick.com>...
<cut>

Raoul, I totally disagree, both with what you say about
On Error Resume Next
and your 'improved' alternative

I suggest that you check out On Error Resume Next very carefully
- you will find that
a) it works
b) use of it makes simpler code

I actually agree that it can make for simpler code and use it myself
(probably more often than I should). When recommending it you should
probably also note that
c) it adds overhead to the app and slows execution
d) it can mask bugs if you don't check for errors after any line that
might generate them

it's fine for short sections of code but not always best for longer
routines.

[J French]

On Wed, 31 Mar 2004 22:30:20 GMT, "Raoul Watson"
<Wa*****@IntelligenCIA.com> wrote:

<snip>

Your method is fine too. I don't have a problem with you having the "last
word".

I really don't care - as long as you make an informed choice

[J French]

On 31 Mar 2004 16:01:32 -0800, bu*******@earthlink.net (Bob Butler)
wrote:

<snip>

I actually agree that it can make for simpler code and use it myself
(probably more often than I should). When recommending it you should
probably also note that
c) it adds overhead to the app and slows execution ... a tadd) it can mask bugs if you don't check for errors after any line that
might generate them Very true
it's fine for short sections of code but not always best for longer
routines.

That is a different subject - but I get your drift

[aaron]

It doesn't work.

If I do a debug.print Err.Number before I call the other function, it prints
out the error number correctly, but once I call the other function and try
to do a debug.print within that function I get a 0.
"Larry Serflaten" <Ab***@SpamBusters.com> wrote in message
news:40********@corp.newsgroups.com...

"aaron" <at******@yahoo.com> wrote

Thanks, with your hints I found that the problem is the error is not being passed to my other function. How do I pass an error object or what is the best way to pass an error if I want to pass both the description and the
number? I have:

The Err Object is a global object. You should not pass it as a parameter.
The called sub will see the same error object that was present in the
caller routine. If you want to clear the error for use in your called

sub, then you will have to store the Err object values before you do anything
that would clear them out.

LFS


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Larry Serflaten]

"aaron" <at******@yahoo.com> wrote

It doesn't work.

If I do a debug.print Err.Number before I call the other function, it prints
out the error number correctly, but once I call the other function and try
to do a debug.print within that function I get a 0.

Show your work. Post a small demo that reproduces that behaviour.

LFS


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----