A 2013 error handling

[Dick7Access]

I am tryhing to fully understand error handling. The code below I copied from someone else and it works fine in the db I have it in. In other db’s and in different code than next record I am trying to create error handling from scratch. Since ErrNumber 2105 refers to next record, what would I use with the procedure is not next record?

  Private Sub cmdNext_Click() 'Lets user know he has reached last record
  On Error GoTo err_handler
     DoCmd.GoToRecord acForm, "frmMain", acNext
      DoCmd.GoToControl "cmbSal"
  cmdNext_Exit:
  Exit Sub
  err_handler:
  If Err.Number = 2105 Then
     MsgBox "You have already reached the Last student.", vbApplicationModal, "That's All Folks"
  Else
     MsgBox Err.Description, vbExclamation, "Error #: " & Err.Number
  End If
     Resume cmdNext_Exit
   End Sub

 

[Dick7Access]

Can anybody tell me why this thread was removed from "new post"?

 

[ChrisO]

Dick.

>>Can anybody tell me why this thread was removed from "new post"?<<

I don't understand what that means but I have now moved this thread to the 'Modules and VBA' forum.

Chris.

 

[Dick7Access]

Hi Chris,
When I posted this thread, it appeared under "New Post". About 5 minutes later it was gone. I was concerened I had violated some rule so I asked. Of course when I ask the question of why it was missing it re-appeared.
Dick

 

[CJ_London]

what would I use with the procedure is not next record?

I would use a case statement rather than an if statment since there are potentially many errors and they may need to be handled differently - e.g.

ErrorHandler:
   Select Case Err
        Case 2103: [COLOR=seagreen]'Have reached the last student[/COLOR]
            MsgBox "You have already reached the Last student.", vbApplicationModal, "That's All Folks"
            Exit Function
        Case 53:[COLOR=seagreen]'File Not found, not critical[/COLOR]
            Resume Next
        Case Else
            MsgBox "There is an untrapped error - Err " & Err & vbCrLf & Err.Description, vbOKOnly, "CODE ERROR"
            Exit Function
    End Select

To find them you need to run your code with just the Case Else part the error handler enabled across all the different permutations of encountering null fields, unassigned variables, etc and add them into your case statement as each one is discovered and the best solution determined

Sometimes an error doesn't matter - for example if you want to delete a file if it exists, if you try to delete it but it doesn't exist, an error is generated (err 53), but that is OK in this situation because you were going to delete it anyway - so you can just resume next.

 

[Dick7Access]

Where can I find a list of all 700+ error handling codes?

 

[CJ_London]

You can try this link

http://www.fmsinc.com/microsoftaccess/errors/errornumber_description.html

 

[Dick7Access]

I would use a case statement rather than an if statment since there are potentially many errors and they may need to be handled differently - e.g.

ErrorHandler:
   Select Case Err
        Case 2103: [COLOR=seagreen]'Have reached the last student[/COLOR]
            MsgBox "You have already reached the Last student.", vbApplicationModal, "That's All Folks"
            Exit Function
        Case 53:[COLOR=seagreen]'File Not found, not critical[/COLOR]
            Resume Next
        Case Else
            MsgBox "There is an untrapped error - Err " & Err & vbCrLf & Err.Description, vbOKOnly, "CODE ERROR"
            Exit Function
    End Select

To find them you need to run your code with just the Case Else part the error handler enabled across all the different permutations of encountering null fields, unassigned variables, etc and add them into your case statement as each one is discovered and the best solution determined

Sometimes an error doesn't matter - for example if you want to delete a file if it exists, if you try to delete it but it doesn't exist, an error is generated (err 53), but that is OK in this situation because you were going to delete it anyway - so you can just resume next.

CJ,
I am still trying to wrap my brain around error handling. This is not any one db, it is to try to increase my access knowledge. I don’t understand how to run “just” the else part of your case function

 

[CJ_London]

If you 'just' want to run the else statement, remove the other two statements or remove the case statement completely and just leave the 'else' part of the code.

Any procedure or function may generate errors, it depends on the code.

I tend to think of it in this way:

1. Some code may not have the potential generate errors at all, in which case you don't need an error handler.
2. Not all errors can occur in any one bit of code
3. The same error can be treated differently in different situations - see 5 & 6 below for an example
4. Some errors can be anticipated - such as the passing of a null value - so can, or should be, handled in your code - by using the nz or isnull functions for example - so again an error handler is not required
5. Some errors don't matter within the context of what you code is doing (such as trying to delete a file that does not exist) so they can perhaps be handled by using 'on error resume next' in your code - or you can use the error handler per the example previously provided.
6. Some errors are potentially fatal in that the code cannot continue without having the error resolved - again these can perhaps be handled within your code, or you can use the error handler - e.g if the code is trying to open a file which does not exist the file not found error is raised (as per the example previously provided) In this case you need the file so your error handler can for example open a file browser for the user to navigate to the correct location so the code can continue. Alternatively the error may be such that the code has to be aborted, but still a) requires an orderly 'exit' - closing objects etc and b) needs to inform the user the the code has been aborted. Reporting the error code and description then helps the developer to track down the problem and recode to resolve it. It also prevents the user from dropping

In a perfect world, all errors would be handled within the code, unfortunately sometimes not all errors are trapped during development time so you need to provide a 'way out'. And sometimes using an error handler is just a tidier way of doing things and keeps you code simpler.

 

[Dick7Access]

If you 'just' want to run the else statement, remove the other two statements or remove the case statement completely and just leave the 'else' part of the code.

Any procedure or function may generate errors, it depends on the code.

I tend to think of it in this way:

1. Some code may not have the potential generate errors at all, in which case you don't need an error handler.

That is part of what was puzzling me. A form that was already open and I filter it, with a cmbutton did not seem to me to need a error hanler. if it did I could figure out what to put in the case or if statment. Thanks so much for your help. Sorry I am so slow learning.

 

[Galaxiom]

Even when an error occurs that is not handled within the procedure it will be passed back up the calling chain of procedures until it finds an error handler.

Consequently if you don't particularly care if the user gets a precise description of the error location, the error handling can be left out of many procedures provided there is something calling it that does have a handler.

When fixing such errors, simply comment out the On Error line of the chain so the code will break and offer debug which will take you to the actual error line.

 

[Dick7Access]

Gal.
do you know any bare bones tutorial on error handling. Everyhing I have googlled combines something else in with it and it throws meoff/
Dick

 

[Galaxiom]

You are probably looking for something that is more complex than it actually is.

I don't use much error handing because I tend to anticipate errors instead. I believe erros should only be processed when they really are errors.

For example I won't let the end of recordset errors CJ London showed as an example ever happen. I make my own navigation buttons and include code so when the focus is on the last record the next button is disabled.

Don't let the user do things they shouldn't. Don't allow attempts to save records until you can ensure that the table will get what it needs.

 

[Dick7Access]

Yes, I believed someone, at some time, at some place that a error handler is needed in every event. Thanks for the advice.