Solved

Access 2010 vba error handling

Posted on 2014-02-04
3
967 Views
Last Modified: 2014-02-04
Hi,

Just a quick question regarding error handling in vba.

Should you implement error handling for each and every vba procedure? For example:

If opening a form to a specific record:
=======================================================
If Not Nz(Me.txtSubsIFAID, "") = "" Then
        Dim strLinkCriteria As String
        strLinkCriteria = "[SubsIFA_ID]=" & Me.txtSubsIFAID & " And [Prop_ID]=" & Me.txtPropID & ""
        DoCmd.OpenForm "frmAddSubsIFA", acNormal, , strLinkCriteria
    End If
=======================================================

or:
DoCmd.OpenForm "frmPolicyPII_AddPolicyNote", acNormal, , acFormAdd

or:
If Me.Dirty Then
        If MsgBox("You have made changes to the 'Client Data' and not saved them." & vbCrLf & vbCrLf & "Are you sure you wish to Exit without saving your changes?", vbYesNo + vbExclamation, "Client Details: Close Screen Alert") = vbYes Then
            Me.Undo
            DoCmd.Close acForm, "frmClientDetails"
        Else
            Exit Sub ' stay on form do nothing
        End If
    Else
        Forms![frmNavMenuForm].[NavMenuSubform].SourceObject = ""
    End If

Many thanks
0
Comment
Question by:andrewpiconnect
  • 2
3 Comments
 
LVL 4

Expert Comment

by:Jack Leach
ID: 39832037
If a person has to ask, then yes, they should.  It's safer,and it's one of those "learn all the rules before you learn where to break them" type of things.

What is sure is that every code that runs absolutely should have an error handler somewhere in the call stack, thus preventing any unhandled errors from ever being raised.

If an error is raised and is not handled in the current procedure, it will look to the procedure that called it, and use the error handler there.  If there's none, it will go the procedure before that one, so on and so forth, until it finds a handler or runs to the bottom of the call stack.  Under no circumstances should it hit the bottom of the call stack without being handled.

Error propagation (as the above is called) can be a helpful tool when understood and used correctly.  As a general rule of thumb though, you're probably better off including basic error handling on every procedure unless you have some specific reason NOT to.

Tools like mz-tools can help greatly with that, in case you're not already aware (google the word, you'll find it).

Cheers,
0
 
LVL 4

Accepted Solution

by:
Jack Leach earned 500 total points
ID: 39832046
As a side note, you can probably get away without it for a small handful of procedures where you can be sure that no error would ever be raised.  Many do, but this begs the question: if I knew an error might be raised, I would have handled it in the code logic already, right?

Anything to do with the form's Dirty property or any DoCmd method, I don't really trust... in the examples you gave, I would definitely use an error handler, as they tend to be prone to non-obvious errors.

So again, once a person can recognize code that is error prone to code that isn't, they can make more informed decisions on when to use error handling and when it's "safe enough" to omit it.  It's probably a better practice to use a handler everywhere, otherwise.
0
 
LVL 75
ID: 39833209
Hey Jack ... welcome to Experts Exchange ...

Joe
0

Featured Post

Highfive + Dolby Voice = No More Audio Complaints!

Poor audio quality is one of the top reasons people don’t use video conferencing. Get the crispest, clearest audio powered by Dolby Voice in every meeting. Highfive and Dolby Voice deliver the best video conferencing and audio experience for every meeting and every room.

Join & Write a Comment

In Debugging – Part 1, you learned the basics of the debugging process. You learned how to avoid bugs, as well as how to utilize the Immediate window in the debugging process. This article takes things to the next level by showing you how you can us…
A simple tool to export all objects of two Access files as text and compare it with Meld, a free diff tool.
Show developers how to use a criteria form to limit the data that appears on an Access report. It is a common requirement that users can specify the criteria for a report at runtime. The easiest way to accomplish this is using a criteria form that a…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now