Error Checking

[Isaac]

If I understand you correctly, all you would have to do is trap for that particular err.Number and simply do nothing and resume where you left off...?

I cannot tell for sure - you may not be understanding (or maybe it's me who doesn't understand what you're suggesting).

Remember, we're already in the error handler, because of some (probably) different error.

So I may have created my code and made some dumb mistake. I get something like "object not set" or whatever.
At that time, my error handler is hit. Inside it, I want to just 'clean up' some other (unrelated to the error) things.
Particularly, I want to kill the log file if it exists. But, I'd like to effective ignore any additional error that occurs while trying to delete it, just give up deleting it at that point.

I think what you're suggesting might be something like this:

Function Foo()
On Error GoTo Errhandler
........code runs, does whatever

ExitFunction:
Exit Function
Errhandler:
if blLogExists then
    On Error Resume Next
    Now try to kill log file
    If err.number=9 then 'permission denied
         Resume ExitFunction
    End if
End Function

The problem is that structure would suffer from the same malady as the first one - the On Error Resume Next (which is what you'd use to allow an error to occur but not hard stop, then check for Err.Number) is totally ignored in the first place.

In both cases, the code never gets past the line that tries to delete the log file.

If I've misunderstood, please post a suggested code structure.

 

[The_Doc_Man]

I am not 100% sure about this, but if I correctly recall the rules of error handling, this sequence cannot work.

Errhandler:
if blLogExists then
    On Error Resume Next
    Now try to kill log file
    If err.number=9 then 'permission denied
         Resume ExitFunction
    End if

The part that bothers me is the ON ERROR RESUME NEXT within the error handler. The catch is that error handling routines cannot see errors in themselves. More specifically, an error trap goes to the first inactive but enabled error handler. In order to execute that ON ERROR RESUME NEXT in that position, you would have to already be in an active error handler. And that IS an executable statement, not a compile-time statement, because you can have sequences that do ON ERROR GOTO 0 followed by ON ERROR RESUME NEXT or ON ERROR GOTO NEW_HANDLER within a routine and they each take effect in proper sequence.

The other problem is this, and it isn't a terrible problem, its more of a "moot point" problem. In that error handler, you will always do nothing. If the flag is TRUE (blLogExists) then (from your comments) you will try to kill the log file. If you get the "Permission Denied" error then you exit the function at its "normal" exit point. But if the error is NOT #9, you fall through to an END FUNCTION - which is the other legal way to exit a handler. And if theblLogExists is FALSE then you also fall through to the END FUNCTION. In any case you do nothing (unless you put code in to delete the file and it actually DOES get deleted.) But as I pointed out above, if there IS an error, this handler will NOT perform the ON ERROR RESUME NEXT.

Then there is questionable wisdom of actually deleting a file from an Exit Handler. Recommended "best practices" for error handlers are to leave behind a trace of their findings, like setting a flag or something, that would then be detected by the main-line event code that had declared the handler.

You DO NOT WANT to slow down your code by engaging in a file operation from within an exit handler. You COULD, if you really wanted, test variables to decide whether some external test has verified your ability to take the desired action. But error handlers are like interrupt routines. Nothing in your code can interrupt an error handler so you are in that context until you RESUME out of the handler OR the first error that occurs inside that handler WILL leave that handler in the dust, since errors cannot interrupt active handlers. They can only stop them.

 

[gemma-the-husky]

@Isaac

out of interest,
Why are you killing all these files inside the error handler?
What error makes the code jump to the error handler?
Kill might error on any of the deletes, so why just try to error protect the third delete?

errhandler:
If blBatExists = True Then
    Kill strBatPath
End If
If blScriptExists = True Then
    Kill strScriptPath
End If
If blLogExists = True Then
    On Error Resume Next
    Kill strDownloadFolderPath & "\WinSCP.log"
End If
GetSourceFile_Method_One = "Error: " & Err.Description
End Function

 

[NauticalGent]

If I've misunderstood, please post a suggested code structure.

No sir, you understood me completely. I cannot offer anything new that hasn't ben offered and, frankly, my understanding of what goes on after an error is raised and in the process of being handled, leaves a LOT to be desired.

The only thing I might consider if it were my app, would be to call a separate sub that would handle the file deletion, either successfully or unsuccessfully and then resume.

I am interested in seeing your answers to Dave's questions.