Error Checking

[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.