Doesnt write errors to log!

I am trying to do an error log thing for my program

I implemented it but unfortunatly - put it this way it wasnt ready for a release!

Now I have the time taken out - what happens is that if there is an error (in fact - WHEN it somehow exists the loop which is a bug!) there will be an error like type mistmatch or error 53 (FNF - File not found) - it doesnt write that to the file! how come?


...
...

on error goto reporterror
'open "A:\sldkfnsdfn.txt" for append as #1
'There should be an error here since there is no file to open or write to!
write #1, "sdfgdfsf"
close #1
exit sub

reporterror:
'file is ALREADY opened from the MAIN form load event - so just add to it
print #4, err.number, err.description

...
...
exit sub




It doesnt write it. It produces the error on the screen and quits the program.

What am I doing wrong?

well..., you should see if is it is actually going to the reporterror:,

I should add that if you can access the A:\ and you open a file.., if it does not exist then it will create the file...

yes I know that but even tho lets say if the file wasnt opened (the commented out line) - it should reporterror..

I think you're going to have to post more of your code, or take Byan's suggestion and make sure it's actually hitting the error-handler. Single-stepping through your code can resolve a lot of problems.

yeh I know what you mean lebb :)

Hmm - i cant really post the code since its "private" :-/

But lets say for some reason a file wasnt open on a floppy disk or an operation in the program encountered an error like overflow or something (shouldnt) - that error never gets written to the error log file.

Get my debugging tutorial here. It tells you how to use App.Startlogging
and App.LogEvent to do error logging without having to worry about the
log process raising errors of its own.
http://www.visualbasicforum.com/showthread.php?threadid=9415

Try using FreeFile instead of hardcoding the file handles (#1, #4). This is just good technique anyway. Make the variable you use to hold the file handle a global variable. I suspect your problem is the scope of your file handle.

Hi again. its late here 2am and im tired lol

Basically i want an error trap - no problem

lets say for example for some stupid reason some person takes out the floppy and the program needs to write to the floppy - how can i tell it to keep looping and access the drive until the file can be opened or until vbcancel is true?

i tried some ways deleted them and used a do loop but everytime you access the drive VB will obviously say disk write error or something (71 error code)

this being one code just now:


Dim accessible As Boolean
Dim erromsg As String

accessible = False

On Error GoTo nodisk
Open "A:\test.txt" For Append As #1
accessible = True
Close #1

nodisk:

If accessible = False Then

If Err.Number = 71 Then

errormsg = MsgBox("No disk in drive", vbRetryCancel, "Test")

If vbRetry Then
On Error GoTo nodisk
Open "A:\test.txt" For Append As #1
accessible = True
Exit Sub
End If

End If

End If

Try using: On Error Resume Next

didnt work


Dim accessible As Boolean
Dim erromsg As String

accessible = False

On Error GoTo nodisk
Open "A:\test.txt" For Append As #1
accessible = True
Close #1

nodisk:

If accessible = False Then

If Err.Number = 71 Then

errormsg = MsgBox("No disk in drive", vbRetryCancel, "Test")

If vbRetry Then
On Error Resume Next
Open "A:\test.txt" For Append As #1
accessible = True
Exit Sub

End If

End If
End If


SECOND code:


Dim erromsg As String

accessible = False

On Error GoTo nodisk
Open "A:\test.txt" For Append As #1
accessible = True
Close #1

nodisk:

If accessible = False Then
Dim duh As String

duh = MsgBox("error disk", vbRetryCancel, "tert")
If vbRetry Then
On Error Resume Next
Open "A:\test.txt" For Append As #1 'HERE!!!
accessible = True
End If
End If

Hmm - i cant really post the code since its "private" :-/
Well, if your code is "private," then you'll probably have to hire some "private" help to fix it for you. As to the examples you've posted, it's pretty clear that you're ignoring reboot's and Thinker's advice anyway. If you read Thinker's debugging tutorial and apply it, it will become very evident that your app is raising new errors inside the error handler itself.

i think u took it the wrong way lebb.....

I am taking their advice - after thinker/reboot posted that guide - I am looking at it :)

stay cool :cool: