Error Checking

[Sun_Force]

MajP will tell you different! On his 1st day here he arrogantly proclaimed how clever s/he is, and how thick the rest of us are... Only a "Thick" person would hold such a view.

Again I'm young and most of members here have more experience in life than me.
But with my limited experience, when I see someone brags about his skills, It gives me the idea he's not that good.
Not long ago, I read somewhere The more I learn, the less I know.
And I believe in it. The more someone improves in a subject, the more he realizes how deep that subject is and how less he knows.
Most of our professors in collage who talk over and over how good they are, simply are not that good.

In case of @MajP, it's a surprise if he had ever said something like that. I had a different view of him.

The more I learn, the more I realize how much I don't know
Albert Einstein

 

[MajP]

You're asking me? I don't know. I'm not a programmer.
But when an application shows you an empty message box, or tells you "This table was made in Excel 2010 and excel 2010 can not open it" or some meaningless messages, apparently something has gone wrong and it hasn't been trapped. Otherwise I should have seen a logical message.

Those errors appeared to be trapped, they are just not being trapped well. The error handler did not make a proper string for the message. If not you would not get a nicely formatted msgbox, it would crash or send you to the vbe if uncompiled.

In case of @MajP, it's a surprise if he had ever said something like that.

I know. Me too,

 

[The_Doc_Man]

MajP, while you do have a bit of an attitude sometimes, I don't believe that statement about "you claiming to write perfect code" is accurate. You will admit when you are wrong. OK, doesn't happen often - but you have been corrected a few times and admitted the error. Don't go looking for examples, though. Needle in a haystack.

But you've got a pretty good batting average. If you could just control that "cornered cat" attitude a bit more, you'd be pretty damned good.

 

[Dave E]

I'm very late to this thread and many of my own thoughts have already been expressed.

However, I'm incredulous that any serious developer would treat it as a matter of pride that they do not use error handling in ACCDB or ACCDE files distributed to clients.

Of course, like any experienced developer, I test my code thoroughly before it is released. I deliberately look for problems so these can be solved before end users are involved. I do this both to ensure UX is as good as I can make it and to protect my own reputation as a developer.

However, I am well aware that no developer is perfect and things may slip through...in extreme cases with errors not being noticed for several years.

As already mentioned, not all possible modes of use can ever be tested...some end users have ways of doing things that can never reasonably be foreseen...and which may lead to very obscure errors.

I ask my clients to report all errors...no matter how trivial...but inevitably that doesn't always happen.
As a result, after over a decade of continuous use by several thousand users of my main schools app I set up detailed error logging with automated emails sent to me (with the clients' permission) as the primary developer listing full details of what/who/when/where/why/how etc.

In the first month, I was inundated with automated emails which allowed me to fix issues going back a long time but that had NEVER been brought to my attention, nor had shown up in any pre-release testing. The majority of those errors pre-dated my own involvement with the application...though not all. Within 3 months, the errors had all been fixed and the emails stopped...to my relief.

That particular app was supplied with a highly locked down ACCDB FE. If it had been an ACCDE, the app would simply have crashed when those errors occurred.

Moving on from unintended programming errors, there are errors that are built in to Access that need to be handled.
There are several examples of this type. For example:
1. A report with no data is loaded from a form. Using the Report_NoData event the report is closed automatically.
However that triggers error 2501 in the calling form .
2. Code is used to select a file or folder using file system object (FSO). If the user cancels, error 5 occurs

In both cases, that error needs to be handled. If not, an ACCDE FE will crash.

So - do enlighten me, how would those be managed without error handling?

I'm not sure I avoided error handling with a sense of pride. But I did take pride in the code I used to prevent errors and the resultant lack of errors reported by the users.
I prefer my own method of - for every step that requires interaction with a user or any transfer of data, internally or externally, check that it will work faultlessly.

 

[isladogs]

I'm not sure I avoided error handling with a sense of pride. But I did take pride in the code I used to prevent errors and the resultant lack of errors reported by the users.
I prefer my own method of - for every step that requires interaction with a user or any transfer of data, internally or externally, check that it will work faultlessly.

I was referring to the comments made by the OP.
We all take pride in checking our code carefully to try and ensure it works correctly. However as my post stated there are errors that will arise in normal use. I gave two examples but there are others. No matter how good our code, error handling is necessary to manage such situations.

 

[isladogs]

This is a pet peeve of mine, and I'm dealing with fellow employees. I've had a vehicle maintenance app running for a long time. I added functionality to sync new repair orders with an outside vendor. It threw an error if this didn't happen properly. My error handling threw up an error that included "notify Paul...". It started failing when the vendor changed something, but nobody told me. Their repair order was still being created and that's all they cared about. Maybe I should implement your email method.

I do recommend it. I used CDO to send the emails to me 'silently' in order to prevent further disrupting the program flow.
The time consuming part was adding the code needed to show precisely what was being done in order to trigger each error.
However, the time spent as more than repaid in terms of time saved in being able to fix any issues quickly.

It also had a side benefit with one client who had been reporting 'random' errors that nobody else could replicate. My approach gave confirmation that all such errors were due to network interruptions (e.g. due to using wifi despite my clear instructions to hardwire all connections) and not my code

 

[NauticalGent]

A very good article on this subject.

 

[NauticalGent]

Below is an excerpt from the Microsoft Access 2010 Programmer’s Reference (ISBN: 978-0-470-59166-6). A very handy book that has taught me a lot. Although I do not agree with everything mentioned in the quote, it is interesting to see how other experts think of the practices mentioned in the thread.

The whole article on Error Handling is informative and it was the first place I saw the additional "Resume" statement used in the Error Handler.

Issues in Error Handling
Some developers try to enhance their error handling with writing log fi les or sending e-mail. There are some issues involved with these error-handling techniques, as explained in the following sections.

Don’t Use Error Handling with Logging.

Some developers write code to insert an error log record into a table or text fi le when an error occurs. The idea is to be able to analyze when and where errors have occurred by querying this table long after the errors happened. However, this technique has some issues.

Access does not provide a way to determine the name of the procedure that is currently running. Because any error logging routine needs to know which procedure caused the error, you need to manually code the name of the current procedure into each error routine. That is labor intensive and prone to errors.
The benefit t of error logging is questionable because few errors should be happening after your code has been tested and delivered. Errors should be rare enough that your users will let you know when they happen. You can always ask them to capture a screenshot if you want to see the details. Some types of errors cause the attempt to log them to fail. Examples include loss of network
connectivity, and disconnected storage hardware. Your user may see additional unrelated
errors, or you could be lulled into thinking that all errors are logged, when they may not be.
If your code is running in a managed environment, it may be benefi cial to log errors to the System
Event Log. For more information on this, refer to Chapter 20. The bottom line is that spending the
time to log unexpected errors to a table or text fi le is not recommended. This is one of those cases
where the benefi ts usually don’t outweigh the costs.
Don’t Use Error Handling That Sends E-Mail
Another interesting way to track the errors that are occurring in an application is to add code to the
error-handling routines that “phone home” when an error occurs. Specifically, the application builds
and sends an e-mail to you (the developer) whenever an unexpected error occurs. This is usually
done with the SendObject method, although there are other ways to utilize MAPI (mail application
programming interface) directly.
This approach has the same problems listed in the preceding section, plus a few more:
‰ Your code needs to be able to send an e-mail using an installed e-mail client. There is
always a possibility that there is no e-mail client installed, or it is not compatible with your
e-mailing code.
‰ Some e-mail clients (for example, Microsoft Outlook) have code to protect against viruses
using the e-mail program to propagate themselves to other computers. If an outside program
(in this case, yours) tries to send an e-mail, a warning message displays, alerting the user that
a virus may be attempting to send e-mail. That isn’t what you want your user to see when
your application is running.
As with error handling with logging, this technique is probably more trouble than it is worth.

 

[Pat Hartman]

Most of our professors in collage who talk over and over how good they are, simply are not that good.

When I take a college course on a technical subject such as SQL Server, I only take courses taught by practitioners who are moonlighting as teachers and never take classes taught by professors.

 

[gemma-the-husky]

I've not read the whole thread, but here's a few areas that may cause problems.

Absolutely ANY disk read or write. Files may not exist, may be in use, may unexpectedly be empty, may be the wrong file for the process, may be formatted badly, may contain bad data.

Any division, just in case you are dividing by zero.

Any possibility of a numeric overflow.

Any possibility of duplicate records or other indexing failures. You either need to pre-read, or have error handling, surely.

Sense checking, although this isn't quite error handling.

Violation of business rules (or logic rules). You try to sell an out of stock item.

Or even - Prevent some fool running a query that deletes or updates data that wasn't supposed to change.

And even more importantly, maybe - When you get an error, how can you safely recover from the error.

 

[gemma-the-husky]

I almost never us error checking, other than using "Resume on Error", which is in extremely rare occasions is the only way to get the code to run.

In millions of executions, I don't remember a single indecent that error checking would have made any differences.
Just continuing to cultivate my pariah persona. What are your thoughts?

From your original post.
In passing, how would you know? If you ignore every error, how can you be sure that the data doesn't include nulls, orphan records and so on? How can you be sure that a data extract accounts for every record that should be accounted for. That's one of the main issues with databases. Nobody ever sees all the data.

I only ever "on error resume next" when I know the error isn't critical. eg try to delete a temporary object that may or may not exist.

on error resume next
delete object

and even then, I might still prefer belt and braces, and test whether the object exists beforehand, and test that the deletion worked.

 

[Isaac]

@Thales750

I think you're confusing real error handling vs. On Error Resume Next.

You say you WANT errors to happen so you know about them. Of course - everyone does. It sounds like you believe that "error handling" means putting "on error resume next", which is, of course, the most foolish way that nobody should handle errors almost ever - that's not what we mean.

In fact, most people's error handling includes methods, sometimes even sophisticated ones, (think Smiley coder's stuff), to report errors in the most meaningful and informative way possible.

But it's just beyond the pale to imagine that you don't have to include anything, that your code will work perfectly.

And yes, harsh as it may sound, there are definitely people[person] on AWF who think they sh*t gold bricks, and say as much in their sig.
Oh well - the important thing isn't to change their minds, pride goes before a fall anyway, the important thing is to avoid being like that onesself...
Which is why I try to admit my wrongs as often as possible....I have said before and will say again, I think humility is one of the most critical elements of a developer's personality. Without it, you will have a difficult time ingesting all of the feedback from the people whose shoulders you are standing on....which means a) you'll learn less, b) you'll have a distorted idea of your own expertise, which leads to more of a)

So yeah - the "I don't have to handle errors" is the result of the lack of humility and questioning one's own work: 2 key elements of a good developer.

All I say is: Keep any opinion you want, just try to avoid admitting this "no error handling" viewpoint in a job interview

PS this thread is like.......crazy! I see this thread as crazier than half the stuff in the Watercooler and Politics forum!
Next we'll be saying we don't back things up, or compile, or put our pants on one leg....

 

[NauticalGent]

on't back things up, or compile, or put our pants on one leg....

yeah, and....?

 

[pbaldy]

Next we'll be saying we don't back things up

Backups?!? We don't need no stinking backups!!

 

[Isaac]

LOL. Seriously it's true, this thread is nuttier even what I mentioned, since I've seen a number of db's being run uncompiled, and of course we've all made mistakes on not backing up enough.

Personally I JUMP into my pants in midair like an Olympian - but that's easy since I still wear them relaxed fit, like it's 1999...

 

[The_Doc_Man]

A very good article on this subject.

A fairly good article except that it glosses over one important fact: After an error is triggered / trapped, you are in a subroutine entered via a hardware trap (including software traps that supply the trap code as though it were a hardware trap). But this subroutine isn't an ordinary subroutine - it is a trap-context subroutine. It has no arguments passed in and has the scope of the module where the trap was declared, not the module where the trap actually occurred.

As it happens, if your error handler falls through to an END SUB then you will return to the caller of the routine that declared the trap. That is because of the way Windows does trap handling. The RESUME statement (which is not legal outside of trap context) is the only way to get back into the context of the routine for which the handler was declared. There would be the temptation to issue a GOTO from the handler to a statement inside the scope of the routine with a trap, but in fact that can cause system failures. (We've had them reported on this forum.)

Many people read the ON ERROR documentation. Not enough people read the RESUME documentation. It is worth attention. Allen Browne uses ON ERROR and RESUME correctly in his example. (As of COURSE he uses it correctly...)

Microsoft Access tips: Error Handling in VBA

How to trap and log the errors reported while a Microsoft Access database is in use. (Access 95 and onwards.)

allenbrowne.com

 

[gemma-the-husky]

@The_Doc_Man

It occurred to me when I looked at the linked code that the error handler did a goto to an exit point for the procedure. I believe exiting the sub ends the scope of the error trap - but it would have been cleaner and more explicit to specifcally resume to that exit point. It's a good habit to minimise what you do in a error-handler (since subsequent errors are ignored until you resume), and generally resume rather goto.

 

[Pat Hartman]

I hate the way Access traps errors. It allows you to use GoTos when you shouldn't.
Resume Next and Resume Exit_Sub arr always my choices. I sometimes add Resume after a different Resume ... which can be useful for testing.

 

[Isaac]

It's a good habit to minimise what you do in a error-handler (since subsequent errors are ignored until you resume)

Did you mean, errors that occur inside an error handler are automatically ignored until you resume? I think you must have meant something else because that is not the case, you will just get an unhandled error.

Or did you just mean that Resume clears the err object and until it's explicitly cleared or Resume then ... ?

 

[isladogs]

@The_Doc_Man

It occurred to me when I looked at the linked code that the error handler did a goto to an exit point for the procedure. I believe exiting the sub ends the scope of the error trap - but it would have been cleaner and more explicit to specifcally resume to that exit point. It's a good habit to minimise what you do in a error-handler (since subsequent errors are ignored until you resume), and generally resume rather goto.

I'm also confused by your comments.
If you are referring to Allen Browne's code in the link given by @The_Doc_Man, there are definitely no GoTo statements in his code.
If you are referring to other linked code, please could you be explicit & state what you are referring to. Thanks

FWIW, I have always used error handling like that in Allen's webpage. For example:

'generic error handling code

Private Sub ErrorHandlingCode()

On Error GoTo Err_Handler

 'code here
   
Exit_Handler:
    Exit Sub
   
Err_Handler:
    strProc = "" 'add proc name here
    MsgBox "Error " & Err.number & " in " & strProc & " procedure : " & vbCrLf & _
        Err.Description, vbCritical, "Program error"
    Resume Exit_Handler

End Sub