Solved Every procedure has error handling?

lacampeona

Registered User.
Local time
Today, 18:23
Joined
Dec 28, 2015
Messages
392
Hello experts.
I was just reading someting about ms access and read this

You actually have to set error handling in every procedure

and then start to think that in my database I do not have any error handling?

So my question is that statment true? I have to make for every procedure error handling?

Can someone tell me how I can do that? Maybe some example?

Thank you
 
You don’t need error handling in every procedure, just those where errors could occur. Good code will handle potential errors before they can occur

for example checking a value is not null or zero before using it is better code than allowing it to cause an error which you then need to manage with an error handler
 
Hi
Ok I see.
So it depends what the code does and what is the purpose?
yes in some cases I have code that if some value is null then msg box and some another action?

my example:
If IsNull(Me.OpombePregledovalec) Then
MsgBox "Pregledovalec- Prosim, če vpišete morebitne opombe oz N/A v polje OpombePregledovalec"
Else
DoCmd.OpenForm "frmKoloneUporabaSignOff"
End If
 
Yes - that is correct, you are preventing an error from happening rather than handling it after it has occurred
 
Ohhh I see and now I undestand what is the purpose of having error handling in the procedure. :unsure:
Ohh Then I was doing right all the time. :)
I have very special database and I am thinking in all possible mistakes that can occur when user will start entering data in the fields.
Thank you very much.
🤗
 
You only need error handling if you are not sure if you have covered all possible errors, your example, so far as it goes, isn’t really about handling an error unless the form being opened relies on the value you are testing
 
Hello
yes I understand what you mean.
My example is about entering a value in some field.
When opening some forms- here I use some events on forms load event and current event so with this I am preventing possible errors?
 
Yes I see
in my case my events disable or enabled some fields on the form so the user can not enter or change data in the field.
 
On the video you can see that the creation of the error management routine is done entirely by hand
But there are tools to 'add' the error handling routine to an existing procedure very quickly
I personally use MzTool but I think there are other tools that can add error handling instructions to any existing routine
At the cost of only pressing Ctrl-E (and therefore a fraction of a second) or other key combination definable before
From a practical point of view, this routine:

Code:
'-------------------------------------------------------------
Function test()
    Debug.Print
End Function
'-------------------------------------------------------------

'by pressing Ctrl-E becomes this:

'-------------------------------------------------------------
Function test()
    On Error GoTo eh_test
    Dim Tempo_Ingresso_Routine As Long, Tempo_uscita_Routine As Long
    Tempo_Ingresso_Routine = Timer
    Debug.Print "modGlobRob2-test", "Timer Ingresso = " & Format$(Tempo_Ingresso_Routine, "00000.000")

    Debug.Print
   
    Tempo_uscita_Routine = Timer
    Debug.Print "modGlobRob2-test", "Timer Uscita   = " & Format$(Tempo_uscita_Routine, "00000.000") & "  Tempo Impiegato = " & Format$(Tempo_uscita_Routine - Tempo_Ingresso_Routine, "000.000")
    Debug.Print "----------------------------------------------------------------------------------"
    Exit Function

eh_test:
    msg_err err.Number, Erl, "test of Modulo modGlobRob2"
    Resume Next

End Function
'-------------------------------------------------------------
 
Last edited by a moderator:
Hello
yes I understand what you mean.
My example is about entering a value in some field.
When opening some forms- here I use some events on forms load event and current event so with this I am preventing possible errors?

There is an old saying that I don't hear very often any more: An ounce of prevention is worth a pound of cure. Perhaps I've outlived those who used to say it? More likely it has been replaced. See later discussion.

While error handler routines are not always hard to code, having an error routine that must undo an SQL action can be daunting, particularly if it would have been possible to prevent the erroneous action with simple tests. If a simple test can prevent a potentially catastrophic recovery effort, why would you NOT make such a test?

We joke a lot about "Murphy's Law" which states "Anything that CAN go wrong WILL go wrong." Nobody ever remembers the last half of the complete quote: "... so make it impossible to go wrong." They forget the quote and the circumstances that led to its original utterance, but we do not forget the principle it espouses. It is this engineering law that brings us shaped connectors that can only be plugged in one way, both with polarized electrical outlets and computer internal connectors with selective bevels or other odd shapes. When Ed Murphy uttered his famous law, software was still in its infancy, but the law echoes throughout our work even today.

In case anyone has forgotten, Ed Murphy was a real person, an engineer at White Sands, New Mexico, USA during some of NASA's early testing of rocket sleds and human endurance. He said those famous words at the meeting after a test in which a human subject suffered a 9-G pullout but the data plugs were backwards - so the test got NO DATA. Those words inspired everyone to look for ways to make things foolproof.

Humans, being even more devilishly ingenious than even Ed Murphy thought, have found ways to defeat "foolproof" precautions, but at least we've thinned the herd of fools in dangerous settings. (Idle thought: Does this mean that we are evolving better fools by culling the herd of the lesser fools?)
 
Error handling should primarily deal with unexpected errors and states that cannot be checked and offer a suitable exit for them in order to keep the system in a defined and processable state and to give the user an understandable message. Values that are missing or wrong are certainly not unexpected, but something like that can be checked.
 
When an unhandled error is encountered it will be passed up the call stack until an error handler is found. Only if none is found will the unhandled error be thrown.

As such it is not necessary to put an error handler on every little procedure when they are called by other procedures.
 
Sometimes something so simple as an NZ function can prevent a small-purpose subroutine from barfing. It's an easy price to pay.
 

Users who are viewing this thread

Back
Top Bottom